Thanks for this. I'll try with L,PT and see whether that works. Mark
-- Dr. Mark Wardle Specialist registrar, Neurology (Sent from my mobile) On 15 Sep 2010, at 23:00, Chuck Hill <[email protected]> wrote: > > On Sep 15, 2010, at 2:17 PM, Mark Wardle wrote: > >> 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 > > Redirected may not be what you want. Last, Pass Through may work better? > Not sure, but maybe worth a try. > >> RewriteEngine on >> RewriteRule ^/$ /cgi-bin/WebObjects/RSNews.woa/ [L,PT] > > >> [note the extra /2 at the end there] > > You need that at some point. The instance where the login is processed has > to be the same instance redirected to after login. > > >> 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... > > I am not sure I understand. After the login, it shows the login again and > logging in a second time works? > > >> It seems to be an issue crossing over between application instances. > > Yes, it is. > > >> See below for additional comments. > > And again. > > >> On 15 September 2010 04:03, Chuck Hill <[email protected]> wrote: >> On Sep 14, 2010, at 1:45 PM, Mark Wardle wrote: > > <snip> > >>> 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 > > Are you storing the session ID in cookies? I am guessing so as it works with > one instance. If not, you will need to append it to the URL. Otherwise, > those URLs look correct. > > >>> 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. > > I don't think you want to remove it. I can't quite see what is wrong yet. > > > Chuck > > > -- > Chuck Hill Senior Consultant / VP Development > > Practical WebObjects - for developers who want to increase their overall > knowledge of WebObjects or who are trying to solve specific problems. > http://www.global-village.net/products/practical_webobjects > > > > > > > _______________________________________________ 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]
