I was thinking it would be nice to be able to enable another user to act as ones proxy in limited circumstances. The way it would work is that the user would send a special private message to the proxy account, stipulating what resources the proxy may access on its behalf. So for instance i might want to let im2 send public chatter on my behalf, so i would do something like: 

/msg im2 permit:chatter

[download]

and then when im2 when to send chatter on my behalf op message would look to see if there was a message like that from me, if there was, then it would be allowed. By deleting the message from the users inbox the permission would disappear. A bit of added infrastructure would allow sending the right message, and of putting it in the archive inbox automatically, and not in the deleted as normally happens.

It seems a simple way to provide this type of functionality, and it doesnt compromise our user communities resources.

---
$world=~s/war/peace/g

Replies are listed 'Best First'.
Re: proxy resource access.
by Corion (Patriarch) on Mar 30, 2006 at 08:04 UTC

    I don't like the idea of creating new users just for any application. I favour the model that eBay uses, where eBay creates for the user a special token, tied to the username and the application it is to be used with. In the case of PM, we could create such tokens based on the user name, the proxy name and the rights the user wants to grant the proxy.

    That will of course need another table to manage the tokens, and checks in all actions that are available to the proxy, but I'd prefer this, as in a case of emergency or a compromised proxy, it's very easy to wipe out all access for that proxy.

    As I see it, the workflow would be like this:

    1. The proxy tells the user its name and what permission it would like, or redirect sthe user to a page on PerlMonks which is set up with the proxy name and the wanted permissions.
    2. The user accepts or modifies these permissions, and is sent to a second page on which PerlMonks displays the token, which the user then pastes into the proxy administration page.
    3. Alternatively, the proxy could supply a redirect URL to which the user is redirected after setting up the token, just like eBay does. This would allow closer integration of the authentication into the proxy application, but also open up a vulnerability potential for cross-site scripting attacks.
    4. The proxy acts on behalf of the users using their tokens
    5. If a user does not submit the request from step 2, no token is generated
    6. Token revocation is easily maintained by the user in a separate step. Of course, token maintenance cannot be farmed out to proxies.
[reply]
Re: proxy resource access. (spoof)
by tye (Sage) on Mar 30, 2006 at 07:16 UTC

    /me runs off to set up home node buttons and links that appear interesting as well as innocent that all do "/msg tye permit:bank-withdrawls"... Step 3: Profit!

    Please don't overload "/msg" with this purpose. It be better stored in a user's settings and the code that sets it should be more paranoid than the rest of our code, at least requiring POST requests, probably requiring that the user re-enter their password.

    - tye        

[reply]

      /me runs off to set up home node buttons....

      Actually that exploit wouldn't work. Since all new messages by a user are created with folder=-1 they wouldnt be recognized as valid. The user would have to go to the their deleted message folder, and undelete it.

      Please don't overload "/msg" with this purpose. It be better stored in a user's settings and the code that sets it should be more paranoid than the rest of our code,

      Hmm, ok if you feel thats really necessary.

      ---
      $world=~s/war/peace/g

[reply]

        Ah, I missed that quirk of your proposal. But it would be nice if people could choose to have their sent messages default to not deleted because they prefer to keep a record of them.

        Hmm, ok if you feel thats really necessary.

        Yes, what is vital in technical decisions is an assessment of tye's emotions.

        So you'd rather have the DB go pawing through all messages sent from X to Y searching for one of the right format? You are going to add infrastructure to make it easy to put this information in a place already defined to have a quite different purpose for what reason? Wouldn't infrastructure to set a user setting be better in so many ways? Private messages should act like private messages, which leads to conflicts if you try to use them for permission granting.

        - tye        

[reply]

Back to Inner Scriptorium