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 <wick...@apache.org> wrote: > There is an existing kerberos plugin that works with twitter.common.http: > https://github.com/twitter/commons/blob/master/src/python/twitter/common/http/plugins/kerberos.py > > 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 <bhu...@apache.org> 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 >> www.livecipher.com >> -- Regards, Bhuvan Arumugam www.livecipher.com
