Communications Express returns to login page when connecting through proxy

Hello,

I installed Communications Suite from JES 05Q4 on frontend and backend servers with latest patches for messaging server, calendar server, and uwc.

Most users can connect and login successfully. But some users have problems when logging to the UWC. The problem is that after the user logs in, he is prompted to log in again, though no error appears in the browser or in the ldap logs. On the same page, after the login fails from the UWC, if the user changes the URL and connects to the Messenger Express, he is granted access directly as if already authenticated.

Some users who are having this problem are on the same LAN as the server but connecting through a proxy. If they bypass the proxy, there will be no problem. Other users are some ISP specific users. i.e. I noticed that users from connecting from specific ISPs are having problems. Whereas connections from other ISPs connect successfully.

I cleared the directory Classcache in the web container. It solved the problem for some while only. Later the problem continued.

Is there any known issue for UWC with some proxies? Or perhaps, does it relate to the Access Manager?

Thanks

[1190 byte] By [klma] at [2007-11-27 4:16:14]
# 1

Hi,

Are you using AM based SSO or Messaging SSO?

When you say you have the 'latest patches' can you be a bit more specific e.g.

showrev -p | grep uwc

showrev -p | grep msg

If you can reproduce the issue with and without the proxy this is good. Have you tried to capture the network trace from the users PC for both combinations and see where there are any obvious differences?

Regards,

Shane.

shane_hjortha at 2007-7-12 9:22:43 > top of Java-index,E-Mail, Calendar, & Collaboration,Sun Java System Messaging Server...
# 2

> Hi,

>

> Are you using AM based SSO or Messaging SSO?

>

I am using AM based SSO.

> When you say you have the 'latest patches' can you be

> a bit more specific e.g.

>

> showrev -p | grep uwc

> showrev -p | grep msg

>

root@front # showrev -p | grep uwc

Patch: 118540-21 Obsoletes: 117287-99, 117819-13, 119156-07 Requires: Incompatibles: Packages: SUNWuwc

Patch: 118540-42 Obsoletes: 117287-99, 117819-13, 119156-07 Requires: Incompatibles: Packages: SUNWuwc

Patch: 118042-16 Obsoletes: Requires: Incompatibles: Packages: SUNWfuwc, SUNWduwc, SUNWeuwc

root@front # showrev -p | grep msg

Patch: 118207-38 Obsoletes: 116800-06, 116568-99, 117781-01, 118002-02 Requires: Incompatibles: Packages: SUNWmsgin, SUNWmsgen, SUNWmsglb, SUNWmsgco, SUNWmsgmt, SUNWmsgst, SUNWmsgmp, SUNWmsgwm, SUNWmsgmf

Patch: 118207-63 Obsoletes: 116800-06, 116568-99, 117781-01, 118002-02 Requires: Incompatibles: Packages: SUNWmsgin, SUNWmsgen, SUNWmsglb, SUNWmsgco, SUNWmsgmt, SUNWmsgst, SUNWmsgmp, SUNWmsgwm, SUNWmsgmf

Patch: 117784-15 Obsoletes: 116802-03, 116570-09 Requires: Incompatibles: Packages: SUNWmsgfr, SUNWmsgde, SUNWmsges

> If you can reproduce the issue with and without the

> proxy this is good. Have you tried to capture the

> network trace from the users PC for both combinations

> and see where there are any obvious differences?

>

No I haven't. But directly after the login to UWC fails by returning to login page, on the same browser's page, if change the URL to the MEM on server, the user directly sees his emails as if already authenticated.

> Regards,

>

> Shane.

Thanks

klma at 2007-7-12 9:22:43 > top of Java-index,E-Mail, Calendar, & Collaboration,Sun Java System Messaging Server...
# 3
Since this is for SOME users, and not all users, I suspect something in the browser, not in your config.SSO (Single SignOn) works with cookies. If these users refuse the cookies, then they will have to log in multiple times. Check for that. . .
jay_plesseta at 2007-7-12 9:22:43 > top of Java-index,E-Mail, Calendar, & Collaboration,Sun Java System Messaging Server...
# 4

> Since this is for SOME users, and not all users, I

> suspect something in the browser, not in your

> config.

>

In fact, it causes problem for users behind the proxy and from some ISPs.

> SSO (Single SignOn) works with cookies. If these

> users refuse the cookies, then they will have to log

> in multiple times. Check for that. . .

I made the UWC pages non-cachable, and it worked out.

It seems the proxy cached the pages on port 80 (the UWC's port), whereas the page returned to the user is on port 8080 (MEM' port). So the correlation on the proxy between these 2 was lost.

Because UWC relies on MEM, and both shall work on different ports, the new versions of UWC shall add in their code that pages shall not be cached.

Thanks

klma at 2007-7-12 9:22:43 > top of Java-index,E-Mail, Calendar, & Collaboration,Sun Java System Messaging Server...
# 5

Hi,

> I made the UWC pages non-cachable, and it worked

> out.

Excellent news.

> It seems the proxy cached the pages on port 80 (the

> UWC's port), whereas the page returned to the user is

> on port 8080 (MEM' port). So the correlation on the

> proxy between these 2 was lost.

>

> Because UWC relies on MEM, and both shall work on

> different ports, the new versions of UWC shall add in

> their code that pages shall not be cached.

Comm-suite-5 has a different architecture for UWC so it shouldn't be affected by this issue. The end-user client no-longer need to contact the MEM directly (if fact the MEM no-longer exists) as the data for the email tab is now retrieved via the UWC interface more along the lines of how the calendar tab works in the 2005Q4.

Regards,

Shane.

shane_hjortha at 2007-7-12 9:22:43 > top of Java-index,E-Mail, Calendar, & Collaboration,Sun Java System Messaging Server...