[the-datatank] Authentication feature

Thu Oct 18 10:39:15 UTC 2012

Hej guys,

Sorry for the late reply, but here's what I propose.

There are 2 possible ways:

1) If the account/token/key is created in the drupal back-end, then the
only thing necessary in order to make The DataTank use this information is
overwriting the* is_authenticated* function in the RController.

2) If you really want The DataTank to hold its stand alone user management
tool, then alot of work will be necessary in order to get this done. This
will be a separate branch which holds new Admin resources that create
tokens/users and hold code that enable managing that information. After
that the *is_authenticated* function will also have to be overwritten.

Also bare in mind that somewhere in december ( or earlier ) we're going to
design the new version of the datatank which takes into account all of the
architectural mishaps from the previous version as well as scalability
problems. In this new version there will be a place for modular
authentication ( so you don't have to overwrite a function with loose code
).

@Dries: I'd go for solution one, I don't have that much time to work on
number 2), as I'm not even sure if will have its place in the roadmap.

Best regards,

Jan

On Thu, Oct 18, 2012 at 9:39 AM, Dries Droesbeke <
Dries.Droesbeke at digipolis.be> wrote:

> Code schrijven is geen probleem, het moet gewoon op de “goei” manier voor
> de TDT roadmap J****
>
> ** **
>
> mvg****
>
> ** **
>
> *Van:* Hannes Van De Vreken [mailto:vandevreken.hannes at gmail.com]
> *Verzonden:* woensdag 17 oktober 2012 18:33
> *Aan:* Dries Droesbeke
> *Onderwerp:* RE: Authentication feature****
>
> ** **
>
> Jan? Have time?****
>
> Met vriendelijke goeten,
> Hannes Van De Vreken
> + 32472730233****
>
> On 17 Oct 2012 17:46, "Dries Droesbeke" <Dries.Droesbeke at digipolis.be>
> wrote:****
>
> bump****
>
>  ****
>
> *Van:* Dries Droesbeke
> *Verzonden:* maandag 15 oktober 2012 9:59
> *Aan:* 'Hannes Van De Vreken'
> *CC:* Jan Vansteenlandt; Geert Van Herbruggen
> *Onderwerp:* RE: Authentication feature****
>
>  ****
>
> I think its cleaner to have the accounts and logging in the tdt db.****
>
> We want to write it ourself but we don’t want a separate path for our fork
> J****
>
>  ****
>
> Do you have an estimate when the decision around this topic will be made?*
> ***
>
>  ****
>
> Regards,****
>
> Dries****
>
>  ****
>
> *Van:* Hannes Van De Vreken [mailto:vandevreken.hannes at gmail.com]
> *Verzonden:* donderdag 11 oktober 2012 20:55
> *Aan:* Dries Droesbeke
> *CC:* Jan Vansteenlandt
> *Onderwerp:* Re: Authentication feature****
>
>  ****
>
> In that case...****
>
>  ****
>
> We can do it quick and dirty. Just write a filter to check the access
> token, find an entry in your drupal db (mysql?), and log the requests in a
> db together with the token, either that be your or our db is to be decided.
> ****
>
>  ****
>
> Met vriendelijke groeten,****
>
> Hannes Van De Vreken****
>
> @hannesvdvreken <https://twitter.com/hannesvdvreken>****
>
> +32472730233****
>
>  ****
>
>  ****
>
> On Thu, Oct 11, 2012 at 4:33 PM, Dries Droesbeke <
> Dries.Droesbeke at digipolis.be> wrote:****
>
> Hi,****
>
>  ****
>
> Your suggestion is a workable solution for us. ****
>
>  ****
>
> Our requirement:****
>
> A user should register in our drupal and in the backend an API
> token/secret should be generated in TDT and returned to consumer in drupal.
> ****
>
> We don’t need an acl based authentication, just a basic auth with those
> credentials would be perfect. The API token and secret can be generated by
> TDT or generated in drupal.****
>
>  ****
>
> In the long run it would be a better solution to have 1 user and multiple
> apps so the request can be tracked back to an application instead of a
> user(with X apps).****
>
>  ****
>
> Oauth is not needed atm.****
>
>  ****
>
> Kind regards****
>
>  ****
>
>  ****
>
> *Van:* Jan Vansteenlandt [mailto:vansteenlandt.jan at gmail.com]
> *Verzonden:* donderdag 11 oktober 2012 10:53
> *Aan:* the-datatank at lists.okfn.org
> *CC:* Dries Droesbeke; Hannes Vandevreken
> *Onderwerp:* Authentication feature****
>
>  ****
>
> Hi list,****
>
>  ****
>
>  ****
>
> Jan here with a question towards the datatank stakeholders, Dries
> Droesbeke from Digipolis Antwerp is working on a datatank installation for
> an antwerp hackaton. He'd also like to authenticate users, currently
> there's no such feature present in the develop branch ( or master branch
> for that matter ). There is however a branch that attempts to perform user
> management and authentication, but I have a feeling the authentication
> needs to be fully integrated instead of partially datatank and partially
> script-wise ( which is now the case in the access list branch ).  ****
>
>  ****
>
> My question is how do you see this user-wise.****
>
>  ****
>
> My suggestion: TDTAdmin/Users -> The resource will be handled by a new
> controller and foresees the following:****
>
>  ****
>
>                    GET: returns all users****
>
>                    HEAD: same as get, but only the headers
>                    PUT/POST: (new_)user as a parameter and adds the user
> to the back-end.****
>
>  ****
>
> My question for Dries is if you expect an api_key in return, after the
> user addition, or will you be passing a password as well through the PUT
> request? Also, you asked for a feature to add tokens/secrets for apps. Do
> you mean OAuth by this? If so, we should take a look at the OAuth API made
> by iRail.****
>
>  ****
>
>  ****
>
> Best regards,****
>
>  ****
>
>  ****
>
> Jan****
>
>  ****
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.okfn.org/pipermail/the-datatank/attachments/20121018/d8e76807/attachment.html>