This is the scoop… we have a very simple DSP page used by users to run some reports and the first time any user is requested by webMethods to enter their login & password for authentication, and this is good (as expected).

If the user closes the browser window and tries to login again by entering the same URL, the webMethods server requests again the login & password, and this is also good.

When the user receives this URL via email and they click on the link and again the first time they are required to enter login & password which is also good.

The problem is if the user receives the email notification with the URL and they click on the link and enter the login & password for the first time and then some time later they decide to close the browser and open it again they are NO LONGER required to enter login & password if the current session has not expired yet. The browser opens a new window without asking the login & passw again and this a security risk.

This is a security glitch and we would like to know if anyone out there had any tips on how to control this better.

Just for the records, our browser setup forces the browser’s temporary internet files folder (aka cache) to be remove when the browser window is closed (see IE options for more details).

Any advice?

Thanks in advance!

Here is our environment: webMethods IS 6.1 with TN 6.1 and IE 6.0 SP2

Btw, I am using Outlook Professional 2003 for Windows XP but I tested using HOTMAIL and I got the same result. It may be a browser configuration, but I would like to know how to control this from the DSP page or maybe setting up the URL in a way that will always force the authentication every time a new browser window is opened.

Hello,

Yemi Bedu

Interesting insight Yemi.

Waldes: If the problem is Outlook using IE to display HTML emails, perhaps a workaround would be sending a plain text email message. Of course, your users would not be able to click links anymore - they’d have to paste them into their browser’s address bar.

But is this a security issue in the first place? After all, the user’s HTTP Basic Authentication credentials were cached by his own browser, right?

Would invoking wm.server:disconnect as a final step in the DSP do the trick? Haven’t tried it but maybe it would work.

The more I think about it the more I think that calling wm.server:disconnect will work. Administrator uses it for the “Log Off” link.

Since you cannot bind the invoke to server:disconnect on browser close, the best bet would be to provide “logoff” link/button.

Guys, the use of wm.server:disconnect would work in a single server environment, but in my case we have a clustered environment and webMethods is aware that there is a bug with wm.server:disconnect and they have created a Feature Request for me because wm.server:disconnect only kills the session in one server but it remains active in the other clustered server.

I am waiting webMethods reply my SR regarding this issue. Once I hear from them I will let you know.

Btw, I like the idea postd by Sonam, this would force the user to open a new browser and copy/paste the url. I thinkk this is an excelent workaround until we get a final word from the software maker.

I will keep you posted.

Thanks a lot for the inputs!

Guys, the use of wm.server:disconnect would work ONLY in a single server environment, but in my case we have a clustered environment and webMethods is aware that there is a bug with wm.server:disconnect and they have created a Feature Request for me because wm.server:disconnect only kills the session in one server but it remains active in the other clustered server.

I am waiting webMethods reply my SR regarding this issue. Once I hear from them I will let you know.

Btw, I like the idea postd by Sonam, this would force the user to open a new browser and copy/paste the url. I thinkk this is an excelent workaround until we get a final word from the software maker.

I will keep you posted.

Thanks a lot for the inputs!

Wierd that they consider this a “feature request” and not an outright bug. No sense logging into the cluster if one can’t logout.

Interesting Yemi. This bug is probably due to them adding session support to the cluster in IS 6.x

From what I know, in IS 4.6, the session would only be local to the IS instance that gets the request, so an intelligent (‘sticky’) loadbalancer is required in front of an IS cluster.

Another thing that might work is making the report generation service ‘stateless’ (this should setup and tear down the session immediately on completion of the request). Now I don’t know how DSPs can be marked to run stateless, but if that’s not possible, a simple service could run the DSP internally (the template services) and return the $txt results.