Application domain differs from portal domain

[Former Member]

Hello Guys ,

I checked the guide and succesfully done yahoo example.

But when I did the same steps for the any HTTP sites in the intranet , I see logon page , I have to enter user name and password which is not acceptable.

I create the system, did user mapping , assign reguired authorizations but user still have to logon to other HTTP system from portal.

In the server log I get "Application domain xxx differs from portal domain yyy".

xxx is the hostname of the internal HTTP server , yyy is the hostname of the domain.Both servers are in the domain.Even I put them in workgroup nothing changes.

How can we pass logon page of intranet sites in the portal?

[detlev_beutner · Accepted solution]

Hi PG,

You mix up several things. The same domain only is needed if the SSO should work via SAPLogonTicket, as this is an issue of cookies and how and when these are sent to a different target (as long as it is the same domain).

If you use user mapping, the domain plays no role, as the mapped username and password are just sent as parameters to the target page.

Use HttpWatch for example to check what data and in which form it is sent to the target server; then you can check why the logon mechanism doesn't work.

> yyy is the hostname of the domain

This part makes technically no sense. A hostname is the prefix of a domain ("x.y.z" => "x" is the hostname, "y.z" is the domain).

Hope it helps

Detlev

[Former Member · Accepted solution]

Hello Detlev,

Sorry for inconvenience.

I did user mapping so it is not a must that HTTP system and SAP Portal are in the same domain.But how can I see HTTP URL without logon page as iview in the portal?The same settings are working for yahoo system but not working for an HTTP system in our intranet.After I did the user mapping I can logon to yahoo over portal without entering user name and password again.Although I follow the sma steps for the HTTP system , did user mapping I see logon page of HTTP system.What can be the reason ?

[detlev_beutner · Accepted solution]

Hi PG,

> But how can I see HTTP URL without logon page as iview in the portal?

> The same settings are working for yahoo system

> but not working for an HTTP system in our intranet

So - something must be different! Check the logon page source code, check i the parameter names are correct, check if some additional parameters are needed (which parameters are maintained within the HTML form fragment) etc.

As said, use for example HTTPWatch to see how the logon is submitted if you are logging in "manually" and how it is submitted using the AppIntegrator.

Hope it helps

Detlev

[Former Member · Accepted solution]

I installl HTTP Watch and checked both of the connections.

The only difference is the http/https.

Our web site is not running on https.And we can not pass the logon page of the site.

[detlev_beutner · Accepted solution]

Hi PG,

I don't expect this to be the difference; and even if, you could call your web app via https, using the corresponding setting in the server definition.

You also should check the post values etc. Also you can try to create some HTML file which calls your webapp, passing the logon name and PW immediately, so that you know in the end what should be submitted to pass the login page immediately.

Hope it helps

Detlev

[Former Member · Accepted solution]

I create a html to pass logon information to our intranet sites.None of them accept the parametres from another HTTP site.So using SSO tickets can solve our problem. It seems user mapping will not work in our system landscape

[detlev_beutner · Accepted solution]

Hi PG,

As far as I can read, you just say "it doesn't work", without really having analyzed <i>why</i> it doesn't work for you up until now... I would suggest first to check the reason as described some times now - the post data, the URL with GET-parameters, the parameters themselves (which param names are expected from the app) etc. pp.

For SSO tickets - of course these ae more easy to maintain (as no mapping have to be maintained), but there are also more restrictions: Now you'd need the same domain, as otherwise the cookie wouldn't be sent; and the application must be able to interpret the ticket (that means, someone has to code the interpretation of the ticket within the application code; that means, it must be under you hands...).

Hope it helps

Detlev