[prev in list] [next in list] [prev in thread] [next in thread] 

List:       forgerock-openam-dev
Subject:    [OpenAM-dev] Integration of OPENAM-379 & OPENAM-307
From:       steve.ferris () forgerock ! com (Steve Ferris)
Date:       2011-01-10 7:40:34
Message-ID: FC1138B4-35DD-4E78-A99A-F3A6F1676E95 () forgerock ! com
[Download RAW message or body]

My take on this is if this back button behaviour is the same as the existing PDP flow \
for the web agents then we can open a new issue, but we can move on. The customer is \
happy with the web agent flow, so the same flow for J2EE would be acceptable.

Steve

-- 
Steve Ferris : ForgeRock AS : e: steve.ferris at forgerock.com
t: +44 (0)7813 709285 f: +44 (0)7971 042421 w: forgerock.com
OpenAM, the new name for OpenSSO

On 8 Jan 2011, at 3:26pm, Marek Detko wrote:

> This JS works in a different way in different browsers. In Safari when I press back \
> button, page is not reloaded but in Firefox request is sent to the server again \
> (dummypost page is requested again, but PDP entry is not available in the cache - \
> was already removed). So I don't think we can use it. Even if pressing back button \
> will not send a new request to the server, how form should be presented to the \
> user? We don't know what kind of form fields were used in the original page so we \
> don't know what kind of filed types should be used on our page. Some original \
> fields could be of type password so we shouldn't make them readable on the page.  
> I'm not a JS specialist so if you give me the JS code working on each browser the \
> same way I can use it. 
> BTW. In current CDSSO scenario when user is already able to get to protected page \
> and presses back button  (Firefox) browser makes request to \
> /agentapp/sunwCDSSORedirectURI and page with status 403 is displayed. 
> Thanks,
> Marek
> 
> 
> On Jan 8, 2011, at 11:18 AM, Major P?ter wrote:
> 
> > If the user presses the browser back button, she will see the already 
> > generated form, the dummypost won't be called, it doesn't matter whether 
> > the cache entry is gone or not, she just will see the form, and the JS 
> > will submit it again.
> > 
> > Regards,
> > Peter
> > 
> > 2011-01-07 21:58 keltez?ssel, Marek Detko ?rta:
> > > 
> > > On Jan 7, 2011, at 7:22 PM, Major P?ter wrote:
> > > 
> > > > If the user presses the browser back button she can still do weird
> > > > things with forms. Like that she can really double POST the form, or?
> > > 
> > > Do we have to take care of it when application URLs will be implemented?
> > > When form will be submitted second time, PDP entry will be already removed from \
> > > the cache and request will be either redirected to application URL (if defined \
> > > in agent config) or access to page will be denied. 
> > > Marek
> > > 
> > > > 
> > > > Regards,
> > > > Peter
> > > > 
> > > > 2011-01-07 19:08 keltez?ssel, Allan Foster ?rta:
> > > > > On 1/7/11 10:04, Marek Detko wrote:
> > > > > > On Jan 7, 2011, at 11:58 AM, Major P?ter wrote:
> > > > > > 
> > > > > > > Two more thing:
> > > > > > > I think we should allow the users to set up URL's for applications, and \
> > > > > > > if the PDP entry is expired or non-existent, then we should redirect \
> > > > > > > the users to those URL's instead of showing a 403. (403 can be a \
> > > > > > > fallback)
> > > > > > What do you exactly mean? An agent configuration property?
> > > > > > 
> > > > > > > Also I saw this thing at Shibboleth SP's:
> > > > > > > http://pastie.org/1436827
> > > > > > > this JS thingy makes sure you're warned when you want to double-POST.
> > > > > > Yes, I agree, this can be added to the page with submitted form.
> > > > > Although strictly speaking it is NOT a double post. The first post was
> > > > > never processed, and this is simply the post, which has to be done from
> > > > > the browser.... since the agent cant "create " a post request.
> > > > > 
> > > > > I dont think it qualifies as a double post, since a double post implies
> > > > > that it is being handled twice.
> > > > > 
> > > > > Allan
> > > > > > thanks,
> > > > > > marek
> > > > > 
> > > > > --
> > > > > ForgeRock 	*Allan Foster* VP Technical Enablement
> > > > > e: allan.foster at forgerock.com<mailto:allan.foster at forgerock.com>
> > > > > t: +1.503.334.2546
> > > > > w: www.forgerock.com<http://www.forgerock.com/>
> > > > > 
> > > > > 
> > > > > The New home for OpenSSO -- OpenAM! It's gonna be BIG!
> > _______________________________________________
> > OpenAM-dev mailing list
> > OpenAM-dev at forgerock.org
> > https://lists.forgerock.org/mailman/listinfo/openam-dev
> 
> _______________________________________________
> OpenAM-dev mailing list
> OpenAM-dev at forgerock.org
> https://lists.forgerock.org/mailman/listinfo/openam-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.forgerock.org/pipermail/openam-dev/attachments/20110110/6d9a9474/attachment.html \



[prev in list] [next in list] [prev in thread] [next in thread]