incubator-couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Adam Kocoloski <kocol...@apache.org>
Subject Re: Custom `user_ctx` attributes
Date Fri, 03 Dec 2010 18:28:09 GMT
+1 from me.  I'm pretty sure nothing would break if a field was added to #user_ctx{}, and adding
an 'aux' field that would host a proplist is a nice way to avoid having to make lots of little
changes to the record in the future.

Adam

On Dec 3, 2010, at 12:04 PM, Alen Mujezinovic wrote:

> Hey guys
> 
> Here's a suggestion about the `user_ctx` record in couch_db.hrl:
> 
> We've been working on custom authentication handlers and one issue came
> up to pass some custom information into `validate_doc_update`.
> 
> We're essentially having a bunch of databases, each of which holds
> documents with user information. Now, instead of passing on the user
> from the `_users` table as `user_ctx`, we're passing on the actual
> user interacting with our application and the current database.
> 
> Think of it this way:
> 
>    - Request comes in for database `foo`.
>    - `Authorization` header is checked against the `_user` database
>    - If it is all right, we look at a custom header `X-App-User` which
>    is essentially a document id.
>    - We look this id up in the database `foo` and get a user document:
> 
>        { _id : "bar", roles: [], yadda: 'yadda'}
> 
>    - We take the `roles` attribute from that document and pass it
>    on as `user_ctx`.
> 
> 
> Now, that seems fine. Our problem though is that there are some cases
> where we would want to pass on more into the `validate_doc_update` function
> than just `user_ctx.name` and `user_ctx.roles`.
> 
> I went with this problem to #erlang, to ask if there's a way to extend
> predefined records with arbitrary attributes, and it turns out that
> this is way too hacky - and possibly would lead to maintenance hell
> down the road.
> 
> Suggestion/Request:
> 
>    Add another attribute `aux` or whatever to the `user_ctx` record,
>    which can be populated with whatever junk one wants to use in
>    `validate_doc_update`.
> 
> 
> Maybe there is already a way and I'm missing it (didn't look too
> closely at the `handler` attribute, figured that is already used for
> something internally) - or better ways to do what we're trying. If so,
> hints please. :)
> 
> Feedback, thoughts? Do you take patches? :)
> 
> Alen


Mime
View raw message