You can, sure. Cross-check with 4.0.x and move the changes forward to your fork.
From: Auke van Leeuwen [mailto:[email protected]] Sent: Monday, March 7, 2016 11:47 PM To: jasig-cas-user <[email protected]> Cc: [email protected]; [email protected] Subject: Re: [cas-user] Encrypted flow keys and redirect=true in webflow Well the good news is that the redirect form in the middle works, but the bad news is that I also have a couple of links like these: <a href="${flowExecutionUrl}&_eventId=no">No, not a subscriber</a> which fail as well on the long url. It kind of sucks (excuse my language) to have to do this everytime and it also doesn't always work that well with the backbutton (i.e. reposting the form). I do have a HA setup btw (the reason why it was changed I think), but I simply use session-affinity (sticky sessions) in the loadbalancer to make sure that I end up on the same node (the one that has the user session). Can I change the executionRepository back to it's former state (i.e. a session based one as in 4.0) or are there more issues with that? Thanks for your time. Auke On Monday, March 7, 2016 at 5:03:43 PM UTC+1, Auke van Leeuwen wrote: 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¶m=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] <mailto:[email protected]> . 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/.
