On 11/10/2011 7:16 PM, Kayode Odeyemi wrote:
On Thu, Oct 6, 2011 at 5:15 PM, Jeff Gaynor <jgay...@ncsa.illinois.edu
<mailto:jgay...@ncsa.illinois.edu>> wrote:

    On 10/06/2011 08:34 AM, Kayode Odeyemi wrote:

        Hello friends,

        I'm working on a pretty large application that I will like to
        use oauth2 on as an authentication and authorization mechanism.

        I understand fairly the technology and I have written my own
        implementation before I stumbled on python-oauth2.

        I need advise on leveraging python-oauth2 api for creating
        consumer key, creating consumer secret, access token and token
        secret.

    This works well, but be advised that the original python oauth
    library had some serious issues, so was redone as python-oauth2.
    What is confusing is that it refers to OAuth version 1.0a, not the
    upcoming OAuth version 2.0, so make sure you read the right spec
    before using it, since they are very different indeed.

    There are *no* usable OAuth version 2..0 implementation in any
    language (usually Java comes first) that I know of, so you will get
    to role your own, which is hard. There are a few beta-level versions
    E.g. Twitter) but these are special cased to the author's needs. The
    spec itself is not quite ready either and since it has changed quite
    substantially in the last year, I suspect that everyone is waiting
    to see it settle to a steady state.

Jeff, I'm in the middle of a big confusion here and will need your help.

I will like to know, can the request be signed just once and for all
subsequent request made, I can use the stored nonce, signature method
and token? My kind of setup is such that, I want the client app to be
registered once, such that for every request to a resource, as long as
the required parameters are available in the header (which would have
been gotten at the initial request), access is granted.

Is this a correct interpretation of Oauth?

I believe every request must be resigned with a new nonce and new timestamp using the tokens it initially fetched during the auth step so "replay" attacks can be prevented. It might be true that some server implementations don't check the timestamp or nonce, so it *might* work for some servers if the exact same request parameters are used, but such servers are simply insecure and broken.

Mark
--
http://mail.python.org/mailman/listinfo/python-list

Reply via email to