esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hirsch, Richard" <>
Subject RE: Other authentication besides OpenID
Date Sun, 29 Mar 2009 07:20:23 GMT
I just found a most recent discussion that talks about authentication on the lift Google group:


From: Hirsch, Richard
Sent: Sun 29.03.2009 09:15
Subject: Other authentication besides OpenID

I'm involved in a variety of different development projects in different roles (consultant,
deployment manager, project manager, etc.) and I'd like to use ESME as a tool in these projects
- private ESME instances. I have two project in particular where I could use ESME to publish
status messages from deployments, server exceptions, tests, svn check-outs, etc. These projects
are currently in progress and I'd love to have the micro-blogging functionality to make the
projects more efficient. They would also provide us with two references.

Many of these projects are internal and protected by firewalls prohibting Internet access
and, thus, have no access to external OpenID sites. As I have discovered with our internal
pilot, there is a certain overhead and complexity of hosting and using internal OpenID sites.
Furthermore, corporate users (irregardless of whether developer or business user) are unnaccustomed
to using OpenID - despite its benefits. The necesity of using OpenID is thus a definite hurdle
for potential corporate users.

Therefore, I'd like to purpose that we support other forms of authentication. Although I'd
love to have container-based authentication but I'd be happy with username/password. If you
look at Buy A Feature ( <> )
which is also lift-based, you'll see that this authentication -type is obviously supported.

If you look at the lift mailing list, there was some suggestions about possible solutions
( <>
) but I have no idea if this made it into Lift 1.0 or not or whether this would help us.

I'm willing to use ESME in my own development projects but without forcing the users to use

I've added a JIRA item to deal with this issue:


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