aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Wickman <>
Subject Re: Authentication for thermos webui
Date Wed, 13 Aug 2014 17:58:11 GMT
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.


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

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message