OK. That's a bit of a challenge (the state completely on the client). So I 
can't really use it redirect=true then I suppose. In this issue 
https://github.com/Jasig/cas/issues/1593 I included some information as to 
why I was using this functionality:

---
Oh btw for a bit more information about the why I use this feature: I'm 
using the pac4j integration to login with a couple of social networks. 
However upon returning from a successful validation I'm trying to find a 
linked account for this social network (i.e. I have a single account that 
can be linked to multiple social networks). I have extended the webflow in 
case no such account is found one is automatigically created or linked to 
an existing account.
The pac4j integration goes something like this:
redirect to social network (save some stuff in the session)
login
come back to callback url (retrieve state from session)
now the callback url looks something like this (top of my head): 
/login?client=someClientId&state=some-difficult-state-identifier&even=more&param=eters.
 
Now at that point I extended the webflow with some extra screens, but the 
URL at that point never changes. For one that is a bit ugly, but more than 
that: If the user presses refresh at some point it will usually error out. 
It's been a while since I implemented this, so I'm a bit fuzzy about the 
details, but I think either on the CAS side some session infrormation has 
been removed or the social network does not accept the accessToken anymore 
to retrieve the UserProfileagain. Either way there was something with kind 
of a one-time state that would trigger ClientAction to fail.
Now that I use redirect=true, my URL changes and the user can press reload.
---

I'll try to implement a sort of auto-posting form in the middle I suppose. 
Any other suggestions?

Auke


On Saturday, March 5, 2016 at 10:57:07 AM UTC+1, Misagh Moayyed wrote:
>
> But in 4.0.x there wasn't a cipher to begin with right? The key is still 
> matched with what there is the session or is all of that no longer stored 
> in the session? I thought it still was actually. 
>
>  
>
>  
>
> *[>] In 4.0.x, Webflow state is entirely managed by the session. It’s not 
> on the client, and you never see it. So yes, no cipher there.*
>
>  
>
> About the external redirect: I always thought that would only be used for 
> an end-state. Wouldn't I lose the context I'm currently in? I think the 
> whole idea of the redirect="true" attribute is to exactly accomplish this. 
> Maybe I could do an external redirect with a flow key, but that is 
> essentially the same as doing it with redirect=true and I still have the 
> issue of the too long URI. Same goes for the JSP way.
>
>  
>
> *[>] I must admit I am not very familiar with that flag. Javadocs also 
> don’t explain much. Could you help me understand what you achieve to do 
> with that flag? And what the end goal is? *
>
>  
>
> I have the feeling that (since 4.0) didn't have the encrypted execution 
> keys, it's still rather safe without the cipher. Or at least as safe as it 
> was in 4.0. Can you confirm that?  Or did something else change that makes 
> it less secure than it was in 4.0?
>
>  
>
> *[>] To recap, the 4.0.x line handles the management of the Webflow state 
> on the server side. Since the client is not involved, the state is not 
> encrypted and is only internally processed by SWF as the repository that 
> manages that state assumes there is a session to work with. In 4.1 and 
> beyond, the Webflow state moves onto the client to remove issues associated 
> with a session specially in an HA environment, and so the state is 
> encrypted. Some changes are being worked on in master to allow for easier 
> configuration of the encryption keys. The keys are required to be generated 
> by you as a deployer, and perhaps not all deployments are aware of that 
> gotcha. *
>
>  
>
> -- 
> You received this message because you are subscribed to the Google Groups 
> "CAS Community" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to [email protected] <javascript:>.
> Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/
> .
>

-- 
You received this message because you are subscribed to the Google Groups "CAS 
Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to [email protected].
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.

Reply via email to