You can easily ensure seamless experience by just issuing a redirect to the CAS server with the service url appended after their password maintenance is done (assuming the CAS Server send that to the password manager).
I would imagine keeping it in the flow would complicate re-use of the password manager in a non-CAS flow scenario (i.e. the user just wanted to change their password). Or is this an in-flow application only and they are required to use another application when they just feel like managing their password? On Tue, Jul 24, 2012 at 10:48 PM, Drew Mazurek <dmazu...@unicon.net> wrote: > My opinion is yes that it should be a part of the login flow so users get > a seamless experience between account maintenance and accessing the > application they were originally trying to get to. If there's another way > of doing that, however, we can look into that instead. > > The scope could also be configurable. By default, put the ticket in the > request scope, but if something like password manager needs it, have it be > in the flow scope. > > - Drew > > On Mon, Jul 23, 2012 at 9:03 PM, Scott Battaglia < > scott.battag...@gmail.com> wrote: > >> Its typically been request scope because its all its needed to be and we >> typically discourage other things from having a handle on it. >> >> I'm not completely against moving it to a different scope, though I also >> wonder at the end what is actually appropriate to put in the login flow >> (i.e. should Password Manager really be considered part of the flow). >> >> Cheers, >> Scott >> >> >> On Mon, Jul 23, 2012 at 9:14 AM, Drew Mazurek <dmazu...@unicon.net>wrote: >> >>> After authentication, can we put the TGT ID in the flow scope rather >>> than the request scope? WebUtils puts it in the request scope, but the >>> password manager occasionally needs to hijack the login flow after >>> authentication but before the user is redirected to the requested service. >>> The problem is that when the password manager is done, the TGT ID that was >>> in the request scope is long gone, and the generateServiceTicket action >>> fails. Unless there was a particular reason why request scope was chosen >>> over flow scope (aside from the fact that the request scope was good enough >>> until now), can I propose the TGT goes into the flow scope? Any thoughts? >>> >>> Thanks, >>> Drew >>> >>> -- >>> You are currently subscribed to cas-dev@lists.jasig.org as: >>> scott.battag...@gmail.com >>> >>> >>> >>> >>> >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/cas-dev >>> >>> >> -- >> You are currently subscribed to cas-dev@lists.jasig.org as: mazu...@gmail.com >> >> To unsubscribe, change settings or access archives, see >> http://www.ja-sig.org/wiki/display/JSG/cas-dev >> >> > -- > You are currently subscribed to cas-dev@lists.jasig.org as: > scott.battag...@gmail.com > > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev > > -- You are currently subscribed to cas-dev@lists.jasig.org as: arch...@mail-archive.com To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
