Hi Chuck - Thank you for these questions - they were enough for me to start properly debugging this myself.
Interestingly, to aid debugging, I removed four of the five application instances and bizarrely found that it seemed to be working perfectly. (It also works perfectly if I go to cvx-neuro01:2001/ for example) As soon as I add an additional instance I start to get login problems. The redirect to the login page is handled perfectly, but the redirect to the original URL fails. Here is an example with two application instances. http://cvx-neuro01/ is redirected by apache to http://cvx-neuro01/cgi-bin/WebObjects/RSNews.woa/wa/login?destinationUrl=%252Fcgi-bin%252FWebObjects%252FRSNews.woa%252F2 [note the extra /2 at the end there] I get the login page... try to login in... get this http://cvx-neuro01/cgi-bin/WebObjects/RSNews.woa/2/wa/login?destinationUrl=%252Fcgi-bin%252FWebObjects%252FRSNews.woa%252F2 login works... It seems to be an issue crossing over between application instances. See below for additional comments. On 15 September 2010 04:03, Chuck Hill <[email protected]> wrote: > > On Sep 14, 2010, at 1:45 PM, Mark Wardle wrote: > > > Hello all, > > > > I have slavishly copied code from Practical Webobjects to handle > just-in-time login. My code works perfectly during development (and I run > through apache for this rather than direct connect) so I was surprised to > see that my redirect AFTER the login page fails to redirect properly. > Indeed, I return to the login page. I cannot explain this behaviour but > think there must be a problem with the code executed after performing login. > > > > Can anyone see any obvious mistake here? > > Is there a better (more robust) way of generating a full URL from the > fragment URI that destinationUrl contains? > > Have I missed a trick within Project Wonder that handles all of this > automatically? > > I remember adding in the wosid in my post-login redirect as it didn't > seem to be appended automatically (before I used cookies) - hence why I did > this manually. > > What are the URLs like in deployment and development? > > > See above. > > This is the superclass of any of my components that require a valid > logged in user > > /** > > * Perform just-in-time login > > */ > > @Override public void appendToResponse(WOResponse response, > WOContext context) { > > if (isPageAccessAllowed()==false) { > > How does this get changed to return true? > > @Override protected boolean isPageAccessAllowed() { if (context().hasSession()) { if (session().authenticatedUser()==null) return false; return session().authenticatedUser().role().canLogin(); } return false; } > > > WOComponent nextPage = > SecureDirectAction.redirectToLoginPage(context); > > nextPage.appendToResponse(response, context); > > } > > else { > > super.appendToResponse(response, context); > > } > > } > > > > > > > > And this is the superclass of any direct action classes that require a > valid logged in user > > > > /** > > * Check that user is logged in prior to executing any direct > actions. > > */ > > @Override public WOActionResults performActionNamed(String > actionName) { > > if (isLoggedIn()==true) { > > How does this get changed to return true? > > public boolean isLoggedIn() { Session session = (Session) existingSession(); if (session!=null) { if (session.authenticatedUser()==null) return false; if (session.authenticatedUser().role()==null) return false; return checkAccessForUser(session.authenticatedUser()); } return false; } > > return super.performActionNamed(actionName); > > } > > return redirectToLoginPage(this.context()); > > } > > > > > > This is the code that generates a redirect to the login page. I used to > generate a plain ol' WORedirect and determine a URL manually for this > > as per Pract WebObjects but decided to go with ERXRedirect and its DA > redirect options instead. > > > > public static final String DESTINATION_URL = "destinationUrl"; > > /** > > * Returns a component that redirects to a login page, remembering > the current page / URL to return to! > > * @param response > > * @param context > > * @return > > */ > > static public WOComponent redirectToLoginPage(WOContext context) { > > > > try { > > ERXRedirect nextPage = (ERXRedirect) > Application.application().pageWithName("ERXRedirect", context); > > nextPage.setDirectActionClass("DirectAction"); > > nextPage.setDirectActionName("login"); > > String uri = context.request().uri(); > > String encodedUrl = java.net.URLEncoder.encode(uri, > "UTF-8"); > > NSDictionary<String, Object> destination = new > NSDictionary<String, Object>(encodedUrl, DirectAction.DESTINATION_URL); > > nextPage.setQueryParameters(destination); > > return nextPage; > > } catch (UnsupportedEncodingException e) { > > throw new NSForwardException(e); > > } > > } > > > > The loginAction() eventually calls this method to redirect back to the > original requesting page: > > /** > > * Creates a redirect that will redirect to the requested landing > page (destination url). > > * TODO: Do we really need to add wosid here? > > * @param session > > * @param destinationUrl > > * @return > > * @throws UnsupportedEncodingException > > */ > > private WOComponent redirectToDestinationUrl(Session session, > String destinationUrl) throws UnsupportedEncodingException { > > String decodedUrl = > java.net.URLDecoder.decode(destinationUrl, "UTF-8"); > > if (session.storesIDsInURLs()==true) { > > decodedUrl = > ERXWOContext.stripSessionIDFromURL(decodedUrl); // remove > existing wosid, if it exists > > decodedUrl = > ERXExtensions.addWosidFormValue(decodedUrl, session); > > } > > else { > > log.debug("Note: we are storing session id in > cookies: therefore not using wosid..."); > > } > > ERXRedirect redirect = (ERXRedirect) > pageWithName("ERXRedirect"); > > // decodedUrl = "http://"; + > session().context().request()._serverName() + decodedUrl; > > log.debug("Finally: redirecting to page: " + decodedUrl); > > What does that log out? > > either /cgi-bin/WebObjects/RSNews.woa/2 or /cgi-bin/WebObjects/RSNews.woa/2/wa/default > > > redirect.setUrl(decodedUrl); > > return redirect; > > } > > > > I think the problem is something to do with default actions and may also > be complicated by apache rewrite rules but I'm confused and as the title > suggests, dimmer than a very dim thing. > > Rewrite rules are also a definite possibility. You can use the same ones > in development to avoid this becoming an issue when you deploy. > RewriteEngine on RewriteRule ^/$ /cgi-bin/WebObjects/RSNews.woa/ [R] Is there a good trick to remove the application identifier from the original url before using it as a destination Url. All of this is to support being able to email out a cleverly created URL to view secure clinical messages so having the JIT login is quite useful really. Mark -- Dr. Mark Wardle Specialist registrar, Neurology Cardiff, UK
_______________________________________________ Do not post admin requests to the list. They will be ignored. Webobjects-dev mailing list ([email protected]) Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/webobjects-dev/archive%40mail-archive.com This email sent to [email protected]
