Sorry if my comment about ajax was confusing. I actually meant the same thing as the original poster. I have a single page application which load everything over an initial route in compojure. Everything after that is done with your wonderful libraries shoreleave-ring/shoreleave-remote together with domina. Maybe i'm just too inexperienced to know, but I'm finding it difficult to figure out how I can use friend to restrict certain users' ability to view modified DOM(since it is a SPA). Do you think you might be able to make a simple example?
-Albert On Monday, April 1, 2013 8:16:42 PM UTC+2, Chas Emerick wrote: > > I think different people are asking different questions here. > > Authenticating via an XHR or similar is very straightforward if you are > using a single-step authentication method like the username/password > interactive workflow. Just POST to the right URL with username/password > data, and carry on based on a successful vs. unsuccessful response. > > Authorization within a single-page application is a totally separate > question. Now that I've read Ari's question again fresh, I think he's > asking "How do I enforce authorization policies when my RPC mechanism (in > this case, shoreleave-remote) 'binds' on a single URI, when it looks like > all the Friend authorization examples establish policy on a per-URI basis?" > > (Apologies to Ari if that's *not* what he's asking, but I'll answer that > question if anyone's interested…) > > The answer is that you can use > `cemerick.friend/authorize`, `cemerick.friend/authorized?`, > `cemerick.friend/throw-unauthorized` > in various combinations whereever you need to enforce authorization policy. > It does not have to be applied only once, just within the boundary of > routing, and it does not even have to be role-based. So, if you expose N > functions via shoreleave's RPC mechanism, each of those (or dedicated > `defremote`s that delegate to other fns) can contain any arbitrary > authorization checks, each potentially changing application behaviour or > throwing an authorization failure as your needs demand. > > That's today, and should suffice for building effectively any application > you need. Someday soon however, it will be possible to back into a > singular routing+authorization policy table for your entire application, > which could include e.g. multiple shoreleave RPC endpoints, each with their > own delimited bag of remote-available fns, each potentially guarded by > their own authorization criteria. This will hopefully allow for > declarative policy specifications, automated reporting of effective policy > outside of runtime, allow you to disentangle authorization policy from the > rest of your codebase, and altogether make audits less invasive and > therefore less costly. > > I hope the above clarifies more than it confuses. > > Cheers, > > - Chas > > On Apr 1, 2013, at 1:12 PM, albert cortez wrote: > > In the same boat here. Trying to make a SPA and now am trying to figure > out the easiest way to have ajax authentification. > > On Tuesday, February 26, 2013 5:24:09 PM UTC+1, Ari wrote: >> >> Hi, >> >> I'd appreciate suggestions on how I can/should secure my >> clojure/clojurescript "single page web" app that relies heavily on >> shoreleave-remote. With other frameworks, upon authentication I've created >> a "roles" cookie that the clientside uses to determine access rights to >> views, while on the serverside I use a "roles" session variable to >> determine access rights to GET/POST data. But Shoreleave side-steps the >> serverside authentication/authorization (via friend), so I'm not sure how >> to proceed. >> >> Thanks. >> >> -Ari >> >> > -- > -- > You received this message because you are subscribed to the Google > Groups "Clojure" group. > To post to this group, send email to clo...@googlegroups.com <javascript:> > Note that posts from new members are moderated - please be patient with > your first post. > To unsubscribe from this group, send email to > clojure+u...@googlegroups.com <javascript:> > For more options, visit this group at > http://groups.google.com/group/clojure?hl=en > --- > You received this message because you are subscribed to the Google Groups > "Clojure" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to clojure+u...@googlegroups.com <javascript:>. > For more options, visit https://groups.google.com/groups/opt_out. > > > > > -- -- 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 --- You received this message because you are subscribed to the Google Groups "Clojure" group. To unsubscribe from this group and stop receiving emails from it, send an email to clojure+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
