aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bhuvan Arumugam <>
Subject Re: Authentication for thermos webui
Date Wed, 13 Aug 2014 20:15:27 GMT
Thank you, Brian.

We'll develop a plugin and track it within thermos observer. When
thermos is re-written using newer frameworks, we'll port the plugin.

On Wed, Aug 13, 2014 at 10:58 AM, Brian Wickman <> wrote:
> There is an existing kerberos plugin that works with twitter.common.http:
> I only bring this up as a reference to prior art.  There's nothing that
> requires this or other plugins to be within the commons codebase and could
> just as easily have been a third party plugin.
> Regarding architecture, the observer is probably the thing that has been
> given the last attention in the last few years and I'm personally open to
> significant architectural change, e.g. porting to Flask and away from
> twitter wrappers, if it means better support for these extensions.  I'm by
> no means a domain expert here and would love community suggestions,
> especially insight into how it's being used.
> ~brian
> On Wed, Aug 13, 2014 at 10:32 AM, Bhuvan Arumugam <> wrote:
>> Hello,
>> We are implementing cookie based authentication for thermos webui
>> (port: 1338). It is a single sign-on implementation. The
>> unauthenticated users will be redirected to a login service. After
>> user is successfully authenticated in the login service, a cookie will
>> be added in this domain. The cookie is validated against the login
>> service, before the page is rendered.
>> I wish to get input on the design we are planning to implement, for
>> thermos webui. Ideally, we want to grant access to thermos webui only
>> for authenticated users.
>> Thermos use twitter.common.http library to render the UI, which use
>> bottle web framework and server. The html pages are generated using
>> bottle templates.
>> We could implement authentication in 2 ways.
>> 1. The authentication can be implemented as a bottle plugin, within
>> thermos code base. The plugin can be installed for each route defined
>> for different web pages. This way, we could avoid making changes
>> directly to twitter.common.http library. We should install this plugin
>> for newer routes/pages added in future.
>> 2. The authentication can be implemented as a bottle plugin, within
>> twitter.common.http library. The plugin can be installed, per
>> application. When it's installed at application level, it is applied
>> to all routes automatically. It will be applicable for newer
>> routes/pages added in future.
>> I'm inclined to go with #1, primarily for single reason: We don't want
>> to fork twitter.common.http library. If we fork, we should come up
>> with a way to integrate it with pants build system, and override this
>> library every time we package thermos. We already forked
>> incubator-aurora for making different changes, and planning to track
>> authentication changes alongside.
>> Is there a better approach to implement authentication?
>> Thank you,
>> --
>> Regards,
>> Bhuvan Arumugam

Bhuvan Arumugam

View raw message