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

Reply via email to