Programmatically setting the ACL

, ,
1

I’m trying to figure out how to set the ACL as to not get the pop-up window, here’s the scenario;

  1. Custom login.dsp (form based for ease of integration into Portal, SSO, etc) ACL is set to anonymous.
  2. Custom login.dsp calls a java service where a context.connect is made with the user name and password supplied to validate.
  3. At this point the user has been “authenticated” and directed to a dsp with an ACL other than anonymous, say ‘service’. The dsp will prompt the user for their credentials again since the login.dsp was set to anonymous.
  4. How can a developer set the ACL so that the correct information is passed from one dsp to another without forcing the user to login in again?
2

This may or may not work, but here goes…

After authenticating, send back a ‘Set-Cookie’ HTTP response header in to the HTTP client, along with a HTTP redirect. Once the cookie has been set, the client should present the cookie to the redirected page (and on subsequent page requests) – hence it may solve your problem.

I imagine your login.dsp would call a Java service with the following code:
com.wm.net.HttpHeader h = Service.getHttpResponseHeader(null);
h.setResponse(302, “Found”);
h.addField(“Location”, “http://intranet/protected_page”);
h.addField(“Set-Cookie”, “ssnid=10asfekt2t2=555513; path=/;”);

(For more info)
On this page: [url=“wmusers.com”]wmusers.com , I mentioned an example with Set-Cookie header. In this post: [url=“wmusers.com”]wmusers.com , I put up some Java code on setting HTTP response headers.

Again, I haven’t tried this but it could work. You can see how IS sets cookies by turning up debug logging in IS (Settings > Logging - set it to 9).

3

Try turning up the debug logging again to check if the HTTP client presents the correct cookie when requesting Test.dsp (i.e. the request made after the 302 redirect). See how the cookie differs when you authenticate manually.

If the cookie is being correctly presented to Test.dsp, and you still get the dialog popup, then perhaps something is wrong the with session being setup (is it expired?, it the login.dsp service stateless? etc?).

Also take a look at your platform? There is also a low chance this could be a bug. For eg, IS 4.6 needed a fix for session expiry… as the README for IS 4.6 FIX 125 states:

When an HTTP client re-connects to the
Integration Server after its session has expired,
all subsequent requests will prompt for
authentication which prevents the request from
being completed.