On Oct 28, 2012, at 2:57 PM, Patrik Sundberg wrote: > I've looked at this for a bit now. It seems there are some slight > inconsistencies in how the redirect info is used: > > Where the redirect-on-autth? is being set up for the interactive-form > workflow it looks to me to be assumed to be a boolean flag. > https://github.com/sundbp/friend/blob/master/src/cemerick/friend/workflows.clj#L79 > > At that point it's given as an argument when setting up the workflow > (defaulting to true). > > Then when it's being used in the generic code it's first picked out - looking > like boolean flag still: > https://github.com/sundbp/friend/blob/master/src/cemerick/friend.clj#L145 > > but then all of a sudden assumed to be a string containing the url to > redirect to: > https://github.com/sundbp/friend/blob/master/src/cemerick/friend.clj#L149 > > Given that, for the interactive-form workflow, it can only be set at the time > of creating the workflow, it seems impossible to actually achieve the flow > where friend "remembers" which page under authentication that user tried to > access, then do auth, and finally return user to the originally requested > page in a dynamic fashion. Since given at workflow creation time it can't > dynamically reflect things properly I'd have assumed. I'd have expected it to > not be an argument at workflow creation time, but the originally requested > url being dynamically kept track of at the point friend realizes it needs to > redirect the user to do authentication, then that url being used on L149 up > there when the workflow sets redirect-on-auth? to true. > > Am I misunderstanding the flow or is there a mixup here? The tests only tests > for boolean state, not as a string url.
You're misunderstanding. If ::redirect-on-auth? is any truthy value (which includes strings), then `redirect-new-auth` will either: (a) send a redirect to the ::unauthorized-uri as captured in the session, which is only ever set if the user previously requested a resource for which they were not authorized (see https://github.com/cemerick/friend/blob/master/src/cemerick/friend.clj#L200), or (b) redirect to the value of ::redirect-on-auth? if it is a string, or (c) redirect to the :default-landing-url specified in the configuration provided to `authenticate`. You're right that (b) will never be the case for the interactive-form workflow, fundamentally because `cemerick.friend.workflows/make-auth` merges the `auth-meta` defaults in last, rather than first. That's a valid point of enhancement; ticket/patch welcome. :-) Note that ::redirect-on-auth? _is_ poorly named: it was originally expected to only be a boolean, thus the '?'. Its name will need to change in the future to reflect its actual role. - Chas -- You received this message because you are subscribed to the Google Groups "Clojure" group. To post to this group, send email to clojure@googlegroups.com Note that posts from new members are moderated - please be patient with your first post. To unsubscribe from this group, send email to clojure+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/clojure?hl=en
