CL_HTTP_CLIENT, Typo3/Mittwald server

We are using CL_HTTP_CLIENT to access a service on the web (another part of the same project). In other words, the SAP-system acts as a client.

The "other side" is using Typo3/Mittwald technology (German).

If I understand correctly, Typo3 is a PHP-based CMS, running on the Mittwald HTTPD. In our case, it is hosted at the Typo3/Mittwald corporation

Does anybody have experience with a similar situation?

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Accepted Solutions (0)

Answers (1)

nope. not me. but what is your actual problem/challenge?

maybe we can help anyway.

regards, anton

You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.

Comment

Right now, I am struggling with the authentication.

At first, we intended to use "basic authentication" (as in Internet RFC 2617), but I have now been told that this poses on practical problems on the Typo3/Mittwald side. The technical person on the Typo3 side writes

The problem about “basic authentication” is that we would
have to move the SAP interfaces outside of the CMS to enable it.
I'd rather prefer to keep it managed by the CMS.

So, naturally, my first question is: which authentication mechanisms are possible that are (relatively) simple on both sides?

At a more general level: where can I find more information on the internet about this technology? (German language no obstacle)

hi,

I think we have Gregor Wolf here who has worked with typo3 integration as far as I know. I hope he jumpes in.

Second, Mittwald is 'just another hoster' specialized in hosting Typo3 projects; so there's probably nothing hoster specific like a Mitwald HTTPD (it rather is an Apache httpd )

Generally , HTTP basic authentication (over SSL if necessary) should be fine both in case of the SAP system and the CMS system being in one network segement as well as in the case where they are on different segments(on two sides of firewalls, etc...).

Single sign on over a logon ticket should also be possible if the certificate can be recognized by the CMS. I think there once was a blog here on SDN on such a solution, probably by Gregor.

You can find your 'direct access' possibilities in transaction SM59 (HTTP destination) and the configurable logon properties there. If those don't work you probably have to find some indirect method over some kind of self-made proxy(but I don't think that's necessary).

More info on Typo3 can be found at www.typo3.org. Note the .org part, here you'll find useful information much easier than on the .com site (as usual ).

Hope it helps a bit,

anton

The web-server identifies itself as "Mittwald HTTPD".

The hosting is at Mittwald (located in the N of Germany) - see also typo3.net .

My guess is that they offer hosting of Typo3 CMSes, running on a Mittwald HTTPD or possibly on a re-branded Apache HTTPD.

You say

HTTP basic authentication ... should be fine

. How does that fit in with the statement made by the technical guy

The problem about “basic authentication” is that we would
have to move the SAP interfaces outside of the CMS to enable it.
I'd rather prefer to keep it managed by the CMS.

okay. sorry. this is the site: http://www.mittwald.de/ . and they really have their own Mittwald HTTPD.

to be honest, I don't understand what they mean with their statement.

What are SAP interfaces inside the CMS?

What kind of authentication would latter require if any?

well, sounds strange to me. sorry that I can't be more of a help.

anton

What are SAP interfaces inside the CMS?

From the perspective of the CMS team: the two services (two URLs) within the CMS that are accessed by the SAP-system.

My guess is: in order to enable basic authentication, they would have two move those two URLs out of the CMS framework and write their own PHP to handle those requests (and to forward the requests - once they are authenticated - to the CMS for execution).

Right now I have been able to get a "200" response, but the content of that response is very different from the content a user with a browser gets.

I have found out that the “Referer” plays an important role.

In normal interactive use, the user first surfs to the server and gets a log-in page.

He fills in user-ID and password and posts a second request to the same server. If the second request does not contain a “Referer” reference to the first page, it does not work.

In our case, we start with the second request.

However, I added a “Referer” reference to the second request (a reference to the first page, that we never used) and I obtained a 200 reponse (success response).

The good news is, this is the first time I have obtained a success response.

The bad news is, that the content is not what I would expect.

The normal surfer gets a response with a normal page.

The SAP CL_HTTP_CLIENT gets a page with many things, among them "Welcome to your new Drupal website! ".

As you can see in my previous posting, there was a bit of Drupal creeping out from underneath the Typo3.

I am surprised! I thought they were "competing" CMSes?

The small success I reported in my posting of the 6th of March has made me think.

It’s probably a matter of 2 requests.

In “normal” interactive use (a human user and a web browser) I think the following happens:

Request 1 is a simple GET.

The response to request 1 has:

a status 403

a body containing an HTML with a log-in form

a cookie

The user executes the HTML, fills in the form and submits. This sets off request 2.

Request 2 is a POST. It has:

user-ID and password in form fields “name” and “pass”

a Referer (because it comes from a web page)

a cookie (the cookie received in the response to request 1)

The response to request 2 has:

a status 200 (we hope)

a body containing the XML

In my calls from SAP (CL_HTTP_CLIENT) so far we only have one exchange:

Request 1 is a POST. It has:

user-ID and password in form fields “name” and “pass”

a Referer (because I fake it)

NO cookie

The response to request 1 has:

a status 200 (yeah!)

a body containing an HTML with a log-in form and the “Welcome to Drupal” stuff

My guess is that the system gets confused (possibly because the request does NOT contain a cookie). Authentication succeeds, but we get the wrong content.

The issue has been solved in a very direct manner: the other team agreed to use "basic authentication" (RFC2617) and that worked from the first attempt.

Ask a Question