I wondered about using repoze classifier's, thanks for the example. This
looks very close to what I envisioned the answer to be....I think I'm still
confused though how this works....sorry I'm being dense I guess but I have
had a heck of time understanding the documentation and source code for this
for some reason...(its me though, not the fault of the documentation)

By setting :
   base_config.sa_auth.request_classifier = my_custom_classifier
   base_config.sa_auth.identifiers = [FLASH_AUTHN_PLUGIN]
   base_config.sa_auth.challengers = [FLASH_AUTHN_PLUGIN]

Am I not overwriting the default behavior that way? How does repoze know
that requests classified as "flash" use one challenger and should otherwise
use something else? Since it looks like identifiers is an array, doesn't
there need to be an entry for the default set of identifiers and challengers
or are those baked in somehow, i.e. something like:
   base_config.sa_auth.challengers = [FLASH_AUTHN_PLUGIN, DEFAULT_THINGGY]
or something like that?

Again, thank you for your patience with my thick-headedness on this...

On Wed, Apr 28, 2010 at 3:54 PM, Gustavo Narea <[email protected]> wrote:

> Hello,
>
> This kind of scenarios are perfectly supported by repoze.who and it's
> not hard to get it working:
>
> You basically need to let repoze.who know which plugins should come
> into play when the client is a browser, and which plugins should come
> into play when it's a flash client. You'd also need to let it know
> what a flash client looks like.
>
> So you want something like this:
> - Browser:
>  - User is identified by the friendlyform plugin (TG2 default).
>  - User is challenged by friendlyform (TG2 default).
> - Flash client:
>  - User is identified by HTTP basic authentication.
>  - User is challenged by HTTP basic authentication.
>
> You already have the browser part, so you need to add the flash part.
> In TG2, you can do it like this:
>    # ===== yourapp.somewhere
>    from repoze.who.classifiers import default_request_classifier
>    from repoze.who.interfaces import IChallenger, IIdentifier
>    from repoze.who.plugins.basicauth import BasicAuthPlugin
>
>    def my_custom_classifier(environ):
>        if environ says the UA is a Flash client:
>            return "flash"
>        return default_request_classifier(environ)
>
>    FLASH_AUTHN_PLUGIN = BasicAuthPlugin("Rob's secret for Flash
> clients")
>    # Optional:
>    FLASH_AUTHN_PLUGIN.classifications = {
>        IIdentifier: ["flash"],
>        IChallenger: ["flash"],
>        }
>
>    # ===== yourapp.config.app_cfg
>    from yourapp.somewhere import my_custom_classifier,
> FLASH_AUTHN_PLUGIN
>    base_config.sa_auth.request_classifier = my_custom_classifier
>    base_config.sa_auth.identifiers = [FLASH_AUTHN_PLUGIN]
>    base_config.sa_auth.challengers = [FLASH_AUTHN_PLUGIN]
>
> That's it.
>
> HTH,
>
>  - Gustavo.
>
> PS: I've just released a new version of repoze.who-friendlyform just
> to make it come into play when the client is a browser. This way it
> won't get in your way:
>
> http://code.gustavonarea.net/repoze.who-friendlyform/News.html#version-1-0-6-2010-04-28
>
> On Apr 27, 2:48 pm, robneville73 <[email protected]> wrote:
> > I'm working on a TG 2.0 project ATM where we are trying to support
> > both a standard HTML-based UI and an API to a flash client via JSON.
> > So far things are going well, but I'm frankly struggling with
> > authentication.
> >
> > Here's the situation. I want to be able to put a repoze predicate on a
> > controller method as normal and have the behavior differ depending on
> > where the request came from. Specifically, I don't want the server to
> > return a redirect 302 when the request has come from my API client and
> > the session isn't authenticated, instead, I want the unmolested 401 to
> > be returned. Conversely, when the request comes from a browser, I do
> > want the default repoze challenger mechanism to redirect me to the
> > login form. I'm running into a brick wall trying to understand the
> > various project documentations and browsing the source code of those
> > projects to understand how I might do that.
> >
> > For other reasons, I've already written some WSGI middleware to
> > distinguish an API request from a normal one, so I have a way of
> > detecting that in the WSGI environment if that helps. Additionally, I
> > have figured out that adding:
> > basic_auth = BasicAuthPlugin('myapp')
> > base_config.sa_auth.identifiers = [('basic_auth',basic_auth)]
> > allows me to send HTTP authentication info in headers coming from the
> > API requests and it appears to be authenticating me.
> >
> > It seems to me that the answer either lies in deciphering repoze's
> > request classifier mechanism for which I've found no good examples of
> > it's use for my purposes, or in perhaps creating my own decorator
> > (i.e. something similar to @require) that I use on wrapped controller
> > methods that only the API client uses - although this solution is less
> > than ideal.
> >
> > I have a feeling that there's an already existing, elegant solution to
> > this but I'm not finding it. HELP PLEASE!
> >
> > Thanks!
> > -Rob
> >
> > --
> > You received this message because you are subscribed to the Google Groups
> "TurboGears" group.
> > To post to this group, send email to [email protected].
> > To unsubscribe from this group, send email to
> [email protected]<turbogears%[email protected]>
> .
> > For more options, visit this group athttp://
> groups.google.com/group/turbogears?hl=en.
>

-- 
You received this message because you are subscribed to the Google Groups 
"TurboGears" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/turbogears?hl=en.

Reply via email to