Auth and Auth

[Yannick Gingras]

Greetings Pyloneers,

It's be a long time since I hacked something with Pylons but things
are moving favorably now. After a flash demo of our great tools, I
was able to convince out lead architect that Pylons was the right
choice for our next web app.

I'm a bit out of sync with the current state of the art so I will need
your help as I refine our technological choices.

First things first, I need to pick an authentication and authorization
solution. Last time I checked, around December, Authkit had a fancy
decorator syntax but it was a bit ill documented and featured many
strange way of authentication that obscured the most straight forward
solution for most people. For that reason, many went the way of
rolling they own authentication. Has anything changed since then?

I will need to support both basic HTTP authentication for our RESTful
API and "forward style" auth for our "human" web interface. Users are
going to come from either the application database or from LDAP. It's
OK to use PAM as a proxy to LDAP since that generally makes
configuration a bit less ugly. (Can we configure auth wiht PAM on
MacOS?) I liked Authkit's decorator syntax; if there is anything
simple like that, it would be great.

That's it, I'm looking for the best auth-and-auth solution that fits
the bill and that isn't too painful to setup. If you all tell me
that I need to roll my own, I think we are going to hack a reusable
authentication package: please tell me what your ideal authentication
system would be like.

--
Yannick Gingras

[Ian Bicking]

It's still quite young, but worth checking out:
http://svn.repoze.org/repoze.who/trunk/

[Wolverine]

Yannick Gingras pisze:

> Greetings Pyloneers,
>
> It's be a long time since I hacked something with Pylons but things
> are moving favorably now. After a flash demo of our great tools, I
> was able to convince out lead architect that Pylons was the right
> choice for our next web app.

Hello!
I'm new to this group, never posted anything here before, but I think
I've got something just right for you. I have done implementation of
HTTP-Auth Basic (Digest is no problem also, but you'll have to change
the controller a bit) and also web based user authentication.

So. Here is my solution for http-auth-basic. Mind you it's not very
fancy, because we are not using http-auth anymore. Also we are using
Elixir as our database model system on top of SQLAlchemy. Since this is
obsolete piece of code it may be not usable, but you can take something
from this and do your own http-auth login controller. It's not
guaranteed it will work.

--- cut ---

from YOURPROJECTNAME.lib.base import *
import base64

class LoginController(BaseController):
""""""

def index(self):
""""""
c.error = session.get('error')
return render('/login/login.mako')

def login(self):
""""""
if not request.headers.has_key('Authorization'):
response.status_code = 401
response.headers['WWW-Authenticate'] = "Basic realm=\"REALM\""
return "Not authenticated"

auth = request.headers['Authorization']
auth_list = auth.split(' ')
auth_type = auth_list[0]
if auth_type == 'Basic':
auth_login, auth_pass =
base64.b64decode(auth_list[1]).split(':')
elif auth_type == 'Digest':
return 'Digest authentication is not yet implemented'

# FIXME: Get account object from database
account_obj = model.Account.query().get_by(email = auth_login)
if account_obj is None:
# FIXME: Show error
abort(404)

# Check if account is active
if account_obj.status == 0:
# FIXME:
session['error'] = 'Account is not active! Cannot login.'
session.save()
redirect_to(action = 'index')

# If passwords do not match
if account_obj.password != auth_pass:
session['error'] = 'Error: Passwords do not match!'
session.save()
redirect_to(action = 'index')

# User authentication succeeded, save logged_user_id in session
session['logged_user_id'] = account_obj.id
session.save()
return redirect_to('login/loggedin.mako')

--- cut ---

As for authenticating website users through website form we have devised
our own system based on Challenge-Response Protocol. Basically the idea
is to create a login controller like this:

controllers/login.py
--- cut ---

class LoginController(BaseController): #TODO: docstring
"""
Login controller class
"""
hash_func = config.get('passwd_hash_func')

def index(self):
"""
Shows login form
"""
c.error = session['error'] if session.has_key('error') else None

# Generate hashed random seed
rand_str = str(datetime.now()) + str(random.randint(100,1000000))
rseed = self.hash_func(rand_str).hexdigest()

# Save this random seed into session
session['login_rseed'] = rseed
session.save()

# Setup form
c.form = login_form(action = h.url_for(controller = 'login',
action = 'login'),
attrs = {'onsubmit' : 'javascript:return
validate_login_form();'},
value = {'rseed' : rseed}
)
c.heading = u"Logowanie"

return render('/login/login.mako')

@validate(form = login_form, error_handler = 'index')
def login(self): #TODO: docstring
"""
Performs login checks
"""
# Check if user is logged
if session.get('logged_user'):
session['error'] = 'User already logged in!'
session.save()
return render('/login/loggedin.mako')

# Get values passed from login form
email = str(request.POST.get('email'))
password = str(request.POST.get('password'))
secure = str(request.POST.get('secure'))

# Remove previous errors
if session.get('error'):
del(session['error'])
session.save()

# Get account from database
account_obj = model.Account.query().get_by(email = email)
if account_obj is None:
session['error'] = 'Error: User does not exist!'
session.save()
redirect_to(action = 'index')

# Generate hash for comparison
apasswd = account_obj.password

# Check if password was sent in secure manner
if secure == 'yes':
# Check if random seed has been passed in session
rseed = session.get('login_rseed')
if not rseed:
session['error'] = 'Error: Random seed doesn\'t exist!'
session.save()
redirect_to(action = 'index')

# Generate hash from seed and password
seedpass = self.hash_func(rseed + apasswd).hexdigest()
else:
# Password was cleartext so we have to hash it
seedpass = apasswd
password = self.hash_func(password).hexdigest()

# Check Challenge Response hashes
if seedpass != password:
session['error'] = 'Error: Bad email or password!'
session.save()
redirect_to(action = 'index')

# If hashes match save user as logged in
session['logged_user'] = email
session['logged_user_id'] = account_obj.id
session.save()

# Send user back to the page he originally wanted to get to
if session.get('path_before_login'):
# Get path before login
redir_url = session['path_before_login']
# Remove path before login from session
del(session['path_before_login'])
session.save()
# Redirect to url
redirect_to(redir_url)
else:
return render('/login/loggedin.mako')

def logout(self): #TODO: docstring
"""
Performs user logout
"""
# Check if user is logged
if not session.get('logged_user'):
session['error'] = 'User is not logged in!'
session.save()
return redirect_to(action = 'index')

del(session['logged_user'])
del(session['logged_user_id'])
session.save()
return render('login/logout.mako')

--- cut ---

And here is the login template:

templates/login/login.mako
--- cut ---

# -*- coding: utf-8 -*-
<%inherit file="/main.mako" />

% if c.error:
<div id="errorbox">
${ c.error }
</div>
% endif

<noscript>
<div id="errorbox">
<h2>Warning!</h2>
You don't have JavaScript enabled. Your password will be unprotected! If
you want to login securely enable Javascript in your browser settings.
</div>
</noscript>

${c.form}

<%def name="metatags()">
${ h.javascript_include_tag('prototypeUtils', 'md5', 'helpers', builtins
= True) }
</%def>

--- cut ---

We are also using ToscaWidgets for creating forms so we have something
like this for the login form:

widgets/forms/login/login.py
--- cut ---

from toscawidgets.widgets import forms
from toscawidgets.api import WidgetsList
from toscawidgets.widgets.forms.validators import Email, UnicodeString,
NotEmpty

forms.FormField.engine_name = "mako"

class LoginForm(forms.Form):
""""""
template = "mako:mibu.templates.forms.default"
submit_text = u"Login"


class fields(WidgetsList):
email = forms.TextField(
validator = Email(not_empty = True),
label_text = u"E-mail:"
)
password = forms.PasswordField(
validator = UnicodeString(not_empty = True),
label_text = u"Password:"
)
rseed = forms.HiddenField(default = '')
secure = forms.HiddenField(default = '')

login_form = LoginForm("login_form")

--- cut ---

The last thing to do is to correct BaseController. We are specifying
requires_auth variable that you can further use in your own controllers
so unauthenticated users are automatically redirected to the login form
and after successful login they are brought back to the page they
requested.

requires_auth is either a list of controller methods or boolean value.
If it's bool and True every action in the controller requires
authentication.

lib/base.py
--- cut ---

class BaseController(WSGIController):
requires_auth = []

def __before__(self, action):
# Check if controller needs authorization
if type(self.requires_auth) == types.BooleanType:
if self.requires_auth:
if 'logged_user' not in session:
session['path_before_login'] = request.path_info
session.save()
return redirect_to(h.url_for(controller = 'login'))
# If requires authorization is list
else:
# Check if action needs authorization
if action in self.requires_auth:
if 'logged_user' not in session:
session['path_before_login'] = request.path_info
session.save()
return redirect_to(h.url_for(controller = 'login'))

def __call__(self, environ, start_response):
"""Invoke the Controller"""
# WSGIController.__call__ dispatches to the Controller method
# the request is routed to. This routing information is
# available in environ['pylons.routes_dict']
return WSGIController.__call__(self, environ, start_response)

--- cut ---

The final thing to setup is JavaScript that encrypts the password before
submiting login form.

public/javascripts/helpers.js
--- cut ---

// String trim function
String.prototype.trim = function() { return this.replace(/^\s+|\s+$/g,
''); }

// Login form validation
function validate_login_form() {
var email = $('login_form_email').getValue();
var password = $('login_form_password').getValue();
var rseed = $('login_form_rseed').getValue();
var secure = $('login_form_secure').getValue();
if (email.trim() == '')
{
alert('Email is not set!');
return false;
}

// FIXME: email address validation

if (password.trim() == '')
{
alert('Password is not set!');
return false;
}
if (rseed.trim() == '')
{
alert('Login error occured!');
return false;
}

// Generate hash
var challenge = gen_challenge(password, rseed);
if (challenge == false)
{
alert('Login error occured!');
return false;
}

// Hide form and change password to challenge hash
hide_element('login_form');
Form.Element.setValue('password', challenge);
Form.Element.setValue('secure', 'yes');

$('login_form').submit();
return true;
}

// Challenge-response authentication generator
function gen_challenge(password, rseed)
{
if (password.trim() == '')
return false;
if (rseed.trim() == '')
return false;
return hex_md5(rseed + hex_md5(password));
}

function show_element(id_name)
{
$(id_name).style.display = 'block';
}

function hide_element(id_name)
{
$(id_name).style.display = 'none';
}

--- cut ---

And this is it. All you have to do to use this authentication is simply
specifying requires_auth = True in your controller or as list of
function names in controller that requires authentication.

If javascript is enabled for user the password will be encrypted for
challenge-response authentication (you can change your hashing function
to another one instead of md5 so you will be secured against md5
dictionary attacks). If javascript is disabled, user still can login,
but he will get a warning that the password will be sent in an unsecure
manner. Of course you can create a decorator so login attempts would be
redirected to https site, but I don't really understand how decorators
work, so I won't help.

I hope this helps. Maybe some of you could refine this code?

Best regards,
Karol Tomala

[Eric Ongerth]

Wow, that's great. I'm just reaching the stage of adding login/
authorization to my project, and your approach looks just like what I
had in mind, but with all the unknowns filled in. Thanks for sharing.

> ...
>
> read more »

[Dalius Dobravolskas]

Hello,

Yannick Gingras wrote:
> First things first, I need to pick an authentication and authorization
> solution. Last time I checked, around December, Authkit had a fancy
> decorator syntax but it was a bit ill documented and featured many
> strange way of authentication that obscured the most straight forward
> solution for most people. For that reason, many went the way of
> rolling they own authentication. Has anything changed since then?

Not really. I should say that AuthKit is great tool but only up to some
degree. Since it is written by genius you need genius to support it.
Since AuthKit's author has many other problems/works to do AuthKit
becomes second class citizen.

The main authentication mechanism I'm using is OpenID. AuthKit's OpenID
implementation is terrible. I have send some patches to author but later
I have seen that it is impossible to fix some problems at all. E.g. in
order to set expire cookie properly you should set two arguments to same
delta or date, because AuthKit OpenID handler uses two session objects
(while one is named cookie handler).

How have I solved this problem? I have decided to split AuthKit into
several independent parts. I was not going to reveal my work to public
yet but because you have raised this question here what I have now (the
main problem that it is even worse documented than AuthKit):

http://hg.sandbox.lt/authopenid-middleware/ - OpenID authentication WSGI
middleware. The main thing I'm working on. I have written Trac OpenID
plugin so I'm just moving my experience from one product to other.

http://hg.sandbox.lt/openidprovider-middleware/ - OpenId provider WSGI
middleware. I have written this one to be able unit-test
authopenid-middleware while it is possible to extend this one to product
of its own. Here is examples of two OpenID servers:
http://hg.sandbox.lt/openidprovider-middleware/file/tip/examples/ - one
allows everything, other demonstrates combination of several middlewares
(I must say I began *LOVING* WSGI).

http://hg.sandbox.lt/authform-middleware/ - Form authentication WSGI
middleware. Very simple middleware demonstrating how easy is to write
authentication middleware. Very early stage.

http://hg.sandbox.lt/authorize-middleware/ - authorize middleware. Very
early stage. And again I will say that AuthKit is amazing piece of
software and you can use AuthKit authorization mechanisms with my
authentication middlewares.

The main problem is that I don't have yet clear vision how middlewares
should be written properly and how they should pass information to other
middlewares. If you have time to analyze my middleware you can see that
I have slightly different vision how authentication middlewares should work.

What I would like to see is some standardization of authentication
middleware. Authorization is easy part when you have authentication
implemented properly. Standardization would allow Pylons' users not
depend on one authentication/authorization vendor (AuthKit in this case).

In general I invite everyone to discuss this problem because it is
really serious problem in Pylons. If you like my approach I invite to
take work on one of my middlewares (because I'm busy person as well) and
fork it. That's what open source is about and distributes VCS (in this
case mercurial) allows us to do after all. That's why I have splitted
AuthKit - because it is too complicated to support it (written by genius
and author is busy person).

> I will need to support both basic HTTP authentication for our RESTful
> API and "forward style" auth for our "human" web interface. Users are
> going to come from either the application database or from LDAP. It's
> OK to use PAM as a proxy to LDAP since that generally makes
> configuration a bit less ugly. (Can we configure auth wiht PAM on
> MacOS?) I liked Authkit's decorator syntax; if there is anything
> simple like that, it would be great.

Use AuthKit. As I have said it is easy to implement authentication
middleware and make it compatible with AuthKit authorization
(decorators). It seems you will need to write one because there is no
(or at least I have not seen) LDAP authentication middleware. While for
authorization use AuthKit (or join my work on
http://hg.sandbox.lt/authorize-middleware/)

Regards,
Dalius

[Dalius Dobravolskas]

Ian Bicking wrote:
> It's still quite young, but worth checking out:
> http://svn.repoze.org/repoze.who/trunk/

How many people are working on it? Will it not end like AuthKit because
no one writes plugin for it? You can write handlers/plugins for AuthKit
as well BTW.

Regards,
Dalius

[chrism]

I am the primary author of repoze.who. I'm currently using it in
customer projects. There are currently four contributors to it,
including myself.

As with any project, it's difficult to know where it will end up, but
I think we're off to a pretty good start, as repoze.who ships with a
good number of plugins, a few third-party plugins have already been
written by various folks. and writing plugins for repoze.who is
actually documented.

Plugins that ship as part of repoze.who:

http://svn.repoze.org/repoze.who/trunk/repoze/who/plugins/

Example plugins for TG2:

http://svn.repoze.org/tg2whoplugins/trunk/

Radius Plugin for repoze.who (contributed by Chris Shenton):

http://svn.repoze.org/whoplugins/whoradius/trunk/

Writing plugins:

http://svn.repoze.org/repoze.who/trunk/README.txt ("Writing a
{Identifier|Authenticator|Challenger|MetadataProvider} Plugin").

FTR, I'm currently communicating with various TurboGears 2 folks about
repoze.who; they are considering making some of their "Authority"
authentication/authorization code rely on it. That's why the tg2
sample plugins exist.

Its current state is completely functional, although it lacks a
configuration file format and parser (maybe one isn't needed, it'd
just be nice). I intend to work more on the documentation, although
it's not completely terrible now.

I'd encourage anybody who is interested in using it but needs help
doing so to join to send mail to the repoze-dev maillist (http://
lists.repoze.org/listinfo/repoze-dev) or just jump on irc.freenode.net
and give a shout in #repoze.

- C


On Mar 28, 2:42 am, Dalius Dobravolskas

[chrism]

I am the primary author of repoze.who. There are four contributors
currently including myself. I am using the software in my own
customers' projects.

As with any project. it's hard to know where it will end up, but I
think we're in pretty good shape now as there have already been some
plugins contributed, and writing repoze.who plugins is fairly well
documented.

See http://svn.repoze.org/repoze.who/trunk/README.txt for
documentation on how to write new plugins.

Existing plugins:

stock: http://svn.repoze.org/repoze.who/trunk/repoze/who/plugins/

TG2 example plugins (written by me with reqt's collaboration with the
TurboGears 2 "Authority" guys): http://svn.repoze.org/tg2whoplugins/trunk/

Radius plugin (contributed by Chris Shenton): http://svn.repoze.org/whoplugins/whoradius/trunk/

I'd be happy to help anybody get started with writing a plugin or two
or advising people how to use the existing ones. Please join the
repoze-dev maillist (http://lists.repoze.org/listinfo/repoze-dev) or
hop into the #repoze channel on irc.freenode.net . It would also be
nice to be able to use some AuthKit implementation code within
repoze.who plugins (they are not really mutually exclusive).

- C


On Mar 28, 2:42 am, Dalius Dobravolskas
<dalius.dobravols...@gmail.com> wrote:

[Chris AtLee]

On Fri, Mar 28, 2008 at 1:08 PM, chrism <chr...@plope.com> wrote:
> I am the primary author of repoze.who. There are four contributors
> currently including myself. I am using the software in my own
> customers' projects.
>
> As with any project. it's hard to know where it will end up, but I
> think we're in pretty good shape now as there have already been some
> plugins contributed, and writing repoze.who plugins is fairly well
> documented.
>
> See http://svn.repoze.org/repoze.who/trunk/README.txt for
> documentation on how to write new plugins.
>
> Existing plugins:
>
> stock: http://svn.repoze.org/repoze.who/trunk/repoze/who/plugins/
>
> TG2 example plugins (written by me with reqt's collaboration with the
> TurboGears 2 "Authority" guys): http://svn.repoze.org/tg2whoplugins/trunk/
>
> Radius plugin (contributed by Chris Shenton): http://svn.repoze.org/whoplugins/whoradius/trunk/
>
> I'd be happy to help anybody get started with writing a plugin or two
> or advising people how to use the existing ones. Please join the
>
> repoze-dev maillist (http://lists.repoze.org/listinfo/repoze-dev) or
> hop into the #repoze channel on irc.freenode.net . It would also be
> nice to be able to use some AuthKit implementation code within
> repoze.who plugins (they are not really mutually exclusive).
>
>
> - C

I started a project called sentry for the purposes of integrating with
existing authentication systems (like PAM, LDAP or DB-based). For the
DB-based plugin you can specify how the passwords in the DB are
hashed. It has hashes that are compatible with Mysql PASSWORD /
OLD_PASSWORD, as well as unix crypt and shadow passwords and
LDAP-style passwords (like "{SHA}...", "{SSHA}...").

For example, to authenticate against an existing phpbb database (which
uses md5 hashes for the password), you could do something like this:

auth = sentry.auth.db.SingleTableAuth("mysql://user:pass@localhost/phpbb",
"phpbb_users", "username", "user_password",
sentry.hashers.Hasher("md5"))

then you can call auth.authenticate(username, password) in your login
function or middleware, which will return whether or not the given
username and password matches. The DB module uses SQLAlchemy, so it
can connect to any DB that SQLAlchemy can.

Basic LDAP authentication is easy:
auth = sentry.auth.ldapauth.LDAPAuth("ldap://ldap.domain.com",
"ou=people,dc=domain,dc=com")

Feel free to use it, or copy code out for your own plugins. You can
find it at http://atlee.ca/software/sentry

Cheers,
Chris

[Mike Orr]

This discussion shows Pylons needs some kind of flexible but standard
system of authentication & authorization. It has also been clear from
the past several months that AuthKit provides *a* unified solution for
both issues, but it has not gained sufficient acceptance from the
Pylons community to be *the* standard.

Given that there's no consensus on which of the existing
implementations to bless, and the fact that some authorization schemes
are so complex they need custom code,
I think it would be in the Pylons tradition to define a minimum spec
for authentication and another for authorization, and then let the
package authors figure out how to fulfill them and to interoperate
with each other; i.e., the WSGI of auth. I've started a wiki page for
this in the Pylons Projects space:

http://wiki.pylonshq.com/display/pylonsprojects/Authentication+and+Authorization+Central

--
Mike Orr <slugg...@gmail.com>

[Ian Bicking]

Some time ago I wrote this up as a proposal for the basic way
authentication can work in WSGI:
http://wsgi.org/wsgi/Specifications/simple_authentication

I think most of the systems work pretty much like this, but I don't know
for sure.

[Jorge Vargas]

On Fri, Mar 28, 2008 at 2:48 PM, Mike Orr <slugg...@gmail.com> wrote:
>
> This discussion shows Pylons needs some kind of flexible but standard
> system of authentication & authorization. It has also been clear from
> the past several months that AuthKit provides *a* unified solution for
> both issues, but it has not gained sufficient acceptance from the
> Pylons community to be *the* standard.
>

this comes as a shock to me, I though authkit was defacto just like
mako, SA,etc. I'm just starting to read up on authkit, and so far I
though it only had outdated documentation, but the fact that noone has
back it up as a good path in this thread makes me wonder if I'm doing
the right thing. Could someone summarize or point to a summary of the
common issues people have with authkit? as for repoze how ready are
you? will I have to work of trunk?

[Mike Orr]

AuthKit's author James Gardner says the architecture is sound, the
outstanding bugs have been fixed, and the two substantial chapters in
the Pylons Book space on the wiki have been audited for Pylons 0.9.6.
Against this are 4-5 people on IRC and this list who have had bad
experiences with AuthKit and think it should be thrown into the ocean.
Their argument seems to be not that it doesn't work (the previous
bugs have been fixed), but that you can write your own authentication
in the time it takes to learn it. I haven't used AuthKit in a program
so I can't say definitively one way or the other. As for the number
of AuthKit discontents, it's impossible to say whether they're a
substantial percentage of the Pylons userbase or a small number of
loud activists.

AuthKit is probably most helpful if you have a complex permissions
scheme and use the built-in plugins. It's less helpful if you use the
"forward" feature to call back into the application for the login
form. In that case you're doing most of the work yourself anyway and
merely shoehorning it into AuthKit's API. In that case you have to
ask whether five lines of AuthKit API calls is really better than five
lines of homegrown code. Probably not, and I think Gardner would
agree here. So the question of whether to use AuthKit mainly comes
down to whether you're happy with its authentication plugins and
authorization models, or whether you'd prefer to replace them with
your own code. And of course, whether the plugins are capable of
doing the kind of authentication you need. For instance, I need LDAP
with a fallback to a local database. I see that AuthKit does both,
but I'm not sure how well it cascades from one to the other, or
whether it will accept my existing Users table.

I first heard about repoze.who last month, but it's modeled after
Zope's authentication which has been around for years. According to
the README in repose.who 0.8, it doesn't do authorization at all, just
authentication.

http://wiki.pylonshq.com/display/pysbook/Home
http://authkit.org/

http://repoze.org/index.html
http://dist.repoze.org/simple/repoze.who/

--
Mike Orr <slugg...@gmail.com>

[Wichert Akkerman]

Previously Mike Orr wrote:
> AuthKit's author James Gardner says the architecture is sound, the
> outstanding bugs have been fixed, and the two substantial chapters in
> the Pylons Book space on the wiki have been audited for Pylons 0.9.6.
> Against this are 4-5 people on IRC and this list who have had bad
> experiences with AuthKit and think it should be thrown into the ocean.
> Their argument seems to be not that it doesn't work (the previous
> bugs have been fixed), but that you can write your own authentication
> in the time it takes to learn it.

There is an important lesson here: a very important, if not the most
important, factor for adaption of a tool such as AuthKit is the quality
of its documentation and how easy it is for complete newcomers to start
using it. I consider myself a reasonably experienced programmer and I
found myself overwhelmed by the complexity of the AuthKit documentation
and setup. If there was a single tutorial that said 'do A and B and
voila! your app is now protected' AuthKit would probably be much more
accepted. Instead there are two pages in the pylons book that try to
cover all of AuthKit, which means they introduce so much complexity that
my first response was 'my needs are very simple, I will look elsewhere'.
After actually using AuthKit since there were no good alternatives at
the time and I did not want to bother to write my own thing I still
think that.

Wichert.

--
Wichert Akkerman <wic...@wiggy.net> It is simple to make things.
http://www.wiggy.net/ It is hard to make things simple.

[lasizoillo]

My problems whith authkit:

I can't say nothing about authkit docs. My english is very bad. I
can't judge it. The code is clear ;-)

AuthKit has many config options. This is a good think. In my work, the
people is mad. Many options for flexibility are welcome.

In SVN version, you have a SQLAlchemy driver for store your users in a
db. The API is strange. You can assign a group to an a user, but you
can't change a user password.

Another thing that dislike me is the data-model. One user belongs to
only one group. In my maddy organization I need that a user belongs to
a many groups (many roles by person). It's easy to implement your own
model whith your own driver. Decorators are great. You don't need
change this. With your own driver you don't need a SVN version of
AuthKit.

The presentation is another tricky thing. You can redirect to your own
url to show a custom auth form. But is not easy to do. You must (or I
doing strange things) make code whith paster auth system. Strange.

I don´t like my solution. Is very strange. Very tricky. I'm studing to
put it in a composite application. But I want do a cleaner solution.

It's possible do many things with AuthKit. But I don't know if is the
correct way.

2008/3/29, Jorge Vargas <jorge....@gmail.com>:

[Dalius Dobravolskas]

Jorge Vargas wrote:

this comes as a shock to me, I though authkit was defacto just like
mako, SA,etc. I'm just starting to read up on authkit, and so far I
though it only had outdated documentation, but the fact that noone has
back it up as a good path in this thread makes me wonder if I'm doing
the right thing. Could someone summarize or point to a summary of the
common issues people have with authkit? as for repoze how ready are
you? will I have to work of trunk?
  

I personally think that AuthKit is great peace of software but I just don't like some aspects of it:

1) OpenID handler is bad:

    a) To make login expire after two days you must set that in two places. That's bad design.

    b) I don't like the way AuthKit handles database with OpenID but I don't have better solution yet either :-(

    c) There are problem with AuthKit OpenID handler you are not even aware yet about.

2) I don't like the idea that AuhtKit tries to display login and other pages itself (either through template or function call). OK - you can pass callback function but that's not solution for me either.

From other side AuthKit *authorization* side is just pure gold.

That's why I offer splitting AuthKit into independent parts.

Regards,
Dalius

[Dalius Dobravolskas]

Ian Bicking wrote:
> Some time ago I wrote this up as a proposal for the basic way
> authentication can work in WSGI:
> http://wsgi.org/wsgi/Specifications/simple_authentication
>
> I think most of the systems work pretty much like this, but I don't know
> for sure.
>

Ian, that's exactly what I want :-) And your specification is almost
perfect. Some notes:

1. AuthKit authorization throws httpexception with code 401

That's why you should handle exception in authentication side before
(matter of one line):

app = HTTPExceptionHandler(app)

Example middleware:
http://hg.sandbox.lt/authform-middleware/file/2be2aba0a1b7/authform_middleware/authform.py

2. I think we should agree that user data if there is some data arriving
with authentication should be put into REMOTE_USER_DATA env. variable.
E.g. some SREG data comes with OpenID authentication and I put it into
dict converted to string ('{"nickname": "dalius"}') and later eval it so
it could be used. I'm not sure if data string must be agreed (e.g.
nickname, locale and etc) or leave that for authentication
plugin/middleware author to fix.

3. It might be possible that pylons will handle error 401 properly even
without WWW-Authenticate header.

Regards,
Dalius

[Dalius Dobravolskas]

Wichert Akkerman wrote:
> There is an important lesson here: a very important, if not the most
> important, factor for adaption of a tool such as AuthKit is the quality
> of its documentation and how easy it is for complete newcomers to start
> using it.

I don't agree here. AuthKit is good enough documented but it just
doesn't fit everyone needs (at least mine). The main problem that is is
under umbrella of one person and is under very slow development.

Regards,
Dalius

[Dalius Dobravolskas]

chrism wrote

> Its current state is completely functional, although it lacks a
> configuration file format and parser (maybe one isn't needed, it'd
> just be nice). I intend to work more on the documentation, although
> it's not completely terrible now.
>

That makes it worse than AuthKit or mine middlewares because AuthKit
relies on WSGI middleware architecture and you can put all configuration
in one file.

Repoze looks like alien object attached to Pylons body. That's only mine
opinion. I actually do not really understand what additional value you
create with repoze. Please, don't take that as personal insult but take
some of your time and explain the philosophy behind repoze.

Regards,
Dalius

[mdoudoroff]

I lack the expertise to judge the relative merits of subtly different
authentication/authorization strategies vis a vis Pylons. I do know,
however, that, as a Pylons "end user", I need a fundamentally sound
and practical authentication/authorization mechanism, and it's the
last thing I want to have to think much about.

Unfortunately, I can confirm that the AuthKit documentation situation
is appalling. I spent hours sifting through the obsolete "Pylons book"
chapters, their comments, the source code, and the cookbook documents
before getting AuthKit running. The enraging thing is that afterwards
I realized that setting up AuthKit is actually quite easy! There's
relatively little to it! Yet the documentation turns it into this
monolithic, impenetrable thing. This is NO WAY to attract new users
(and eventual contributors) to Pylons! Fundamental stuff like this has
to be fundamentally EASY, or people are going to look elsewhere.

It seems to me that AuthKit may have a few warts:

1) The "one group per user" limitation seems to be irritating people.
I don't personally care, because all I need are roles, and I can't
help but wonder if the people who are complaining about user groups
really need the groups or if they're just confused about the
distinction because the documentation is such a disaster.

2) Some of the authentication plug-ins may be under-developed. Some
people here are saying the OpenID stuff doesn't work very well. I
don't know a thing about it, but I see that OpenID is getting pretty
pervasive, so it will probably be increasingly critical to would-be
Pylons adopters.

3) The options for how log-in screens are presented with AuthKit seem
too constricted or inelegant for some people. I'm just starting to
look into this myself, but I have no opinion, yet. I will say that
it's something that should just happen "out of the box" and it should
be darn easy to customize.

That several different parties have initiated their own parallel
authentication kits for Pylons while nobody can be bothered to put a
few hours into updating and completing AuthKit's documentation is
really disconcerting. It does not say that Pylons is a flexible
platform with a wealth of options. It says Pylons is a fragmentary,
incomplete, incoherent platform that can only get you part of the way
there.

I'm a refugee from an old python framework--Webware for Python--that was
rife with derelict components from the get-go. It just looked
terrible. It was embarrassing. There were consequences: the community
waned far more than it waxed. I just got serious about Pylons. I think
it does a lot of things right, apparently with much credit due Ian
Bicking. I apologize for dropping this rant into this thread, but I
want to emphasize how big a problem this is for Pylons.

If I could just volunteer to "address the problem", I would, but I'm
just not qualified yet. About all I can do is write up my own
experiences with AuthKit and post them somewhere if I can find an
appropriate place for them. Perhaps I will. Meanwhile, I hope some
more shakes out soon on this thread, because this dialogue is really
really important.

[Mike Orr]

On Sat, Mar 29, 2008 at 4:23 PM, mdoudoroff <martin.d...@gmail.com> wrote:
> Unfortunately, I can confirm that the AuthKit documentation situation
> is appalling. I spent hours sifting through the obsolete "Pylons book"
> chapters, their comments, the source code, and the cookbook documents
> before getting AuthKit running. The enraging thing is that afterwards
> I realized that setting up AuthKit is actually quite easy! There's
> relatively little to it! Yet the documentation turns it into this
> monolithic, impenetrable thing. This is NO WAY to attract new users
> (and eventual contributors) to Pylons! Fundamental stuff like this has
> to be fundamentally EASY, or people are going to look elsewhere.

We need somebody who has used AuthKit to write the simple HOWTOs that
people are asking for. It sounds like you're qualified, if you're
willing. The reason documentation is slow is that fewer people build
authenticated sites than use SQLAlchemy/Genshi/forms, so there are a
fewer number of people qualified to write auth documentation and to
compare alternative auth libraries.

The two chapters are part of a book that aims to be a complete
reference of Pylons programming, scaling to large sites. I guess they
don't work as well outside that context. The complete book draft is
supposedly going to be finished this week, so hopefully we'll have a
copy online soon.

The fact that James wrote both AuthKit and the book, and would like to
see both as Pylons' standard, yet he responds to email sporadically
(sometimes yes, sometimes no, sometimes a month later), has made it
difficult to resolve the issues around AuthKit. This leaves the rest
of us in a bit of a take-it-as-is-or-use-something-else situation.

> It seems to me that AuthKit may have a few warts:
>
> 1) The "one group per user" limitation seems to be irritating people.
> I don't personally care, because all I need are roles, and I can't
> help but wonder if the people who are complaining about user groups
> really need the groups or if they're just confused about the
> distinction because the documentation is such a disaster.

Could be.

> 2) Some of the authentication plug-ins may be under-developed. Some
> people here are saying the OpenID stuff doesn't work very well. I
> don't know a thing about it, but I see that OpenID is getting pretty
> pervasive, so it will probably be increasingly critical to would-be
> Pylons adopters.

OpenID is a new and different kind of authentication system, so I
don't know if we've figured out the best way to integrate it yet.
Feedback from those who use OpenID would be helpful.

> 3) The options for how log-in screens are presented with AuthKit seem
> too constricted or inelegant for some people.

That may be.

> I'm just starting to
> look into this myself, but I have no opinion, yet. I will say that
> it's something that should just happen "out of the box" and it should
> be darn easy to customize.
>
> That several different parties have initiated their own parallel
> authentication kits for Pylons while nobody can be bothered to put a
> few hours into updating and completing AuthKit's documentation is
> really disconcerting. It does not say that Pylons is a flexible
> platform with a wealth of options. It says Pylons is a fragmentary,
> incomplete, incoherent platform that can only get you part of the way
> there.
>
> I'm a refugee from an old python framework--Webware for Python--that was
> rife with derelict components from the get-go. It just looked
> terrible. It was embarrassing. There were consequences: the community
> waned far more than it waxed. I just got serious about Pylons. I think
> it does a lot of things right, apparently with much credit due Ian
> Bicking. I apologize for dropping this rant into this thread, but I
> want to emphasize how big a problem this is for Pylons.

I also started with Webware after being disilusioned with monolithic
Zope. But I didn't like its servlet paradigm, borrowed from Java. Or
its accessor methods or .camelCase. Webware also named its
components *Kit, which makes me wish AuthKit was called something
else. Quixote seemed much more streamlined and minimalistic so I made
several sites in that. But when WSGI came along I wanted something
that was fully WSGI and modular down to the core, and Pylons is the
only one of those.

Pylons aims to contain the most essential tools but does not make
arbitrary choices about everything. So it includes Mako but also
documents Genshi. It includes FormEncode/htmlfill/webhelpers but also
documents ToscaWidgets and Django newforms. That's because we're not
convinced that any of these form libraries are the "best" answer, but
FormEncode/WebHelpers are an unobtrusive set of modular tools, so more
in keeping with the Pylons philosophy. Pylons had built-in database
support but found it couldn't keep up with the libraries, so it
dropped that in favor of merely supporting SQLAlchemy in the
documentation. Pylons 0.9.7 offers a default SQLAlchemy model as a
convenience, but you can take it or leave it.

Regarding auth, that has never been seen as a core Pylons
responsibility. If you want a framework with a built-in auth library,
see TurboGears. Nevertheless we want to support auth in the
documentation, either with AuthKit alone or AuthKit plus
alternatives.

As Pylons has partnered with TurboGears over the past six months, each
has focused on its unique strengths. TG chooses a set of batteries
for all aspects of web programming. Pylons focuses on a small set of
essential tools, yet the documentation also shows how to integrate
extra libraries. Generally we choose one library to recommend by
default, yet try to show how to use the alternatives too, so users
aren't reinventing the wheel from scratch. That has been one of my
personal goals, which is why I've worled so much on the sQLAlchemy
documentation even though SQLAlchemy is not a Pylons dependency.

To answer another question in this thread, repoze is a set of
WSGI-compatible libraries spun off from Zope. It's the most
exciting contribution from Zope since ZODB, because it allows Zope
products like Plone and other WSGI apps to be mixed in the same site.
However, it's all brand new so it hasn't been fully evaluated which
parts are most useful in Pylons apps. Again, we need feedback from
people who try repoze.who.

AuthKit was written for Pylons and uses the Pylons configuration
system. Nobody has yet evaluated how to integrate repoze.who into
Pylons' configuration, or whether it's worth it. I've heard praise
for AuthKit's authorization but not for its authentication. Maybe the
two will be split someday; that was part of my hope for the wiki page,
that we'd pin down exactly what we need in an authentication system,
and then make it easier for AuthKit to interoperate with other
compliant systems. And simultaneously fill the gaps in AuthKit's
documeentation and features to make it suitable as Pylons' first
recommendation, since it is the only one specifically built for
Pylons.

Nobody has put any feedback on the wiki page yet. :( I renamed it so
here's the current URL:
http://wiki.pylonshq.com/pages/viewpage.action?pageId=11698714

--
Mike Orr <slugg...@gmail.com>

[Ian Bicking]

Dalius Dobravolskas wrote:
> Ian Bicking wrote:
>> Some time ago I wrote this up as a proposal for the basic way
>> authentication can work in WSGI:
>> http://wsgi.org/wsgi/Specifications/simple_authentication
>>
>> I think most of the systems work pretty much like this, but I don't know
>> for sure.
>>
>
> Ian, that's exactly what I want :-) And your specification is almost
> perfect. Some notes:
>
> 1. AuthKit authorization throws httpexception with code 401
>
> That's why you should handle exception in authentication side before
> (matter of one line):
>
> app = HTTPExceptionHandler(app)
>
> Example middleware:
> http://hg.sandbox.lt/authform-middleware/file/2be2aba0a1b7/authform_middleware/authform.py

Generally you shouldn't throw expected exceptions outside of your
application. So HTTPExceptionHandler should be wrapping your
controllers directly, and should translate any HTTPAuthorizationRequired
exceptions into proper 401 responses. I don't think the auth middleware
should wrap these itself.

> 2. I think we should agree that user data if there is some data arriving
> with authentication should be put into REMOTE_USER_DATA env. variable.
> E.g. some SREG data comes with OpenID authentication and I put it into
> dict converted to string ('{"nickname": "dalius"}') and later eval it so
> it could be used. I'm not sure if data string must be agreed (e.g.
> nickname, locale and etc) or leave that for authentication
> plugin/middleware author to fix.

evaling is generally a bad idea. You could consider it JSON or some
more limited serialization of data. Or put it in, say,
environ['x-wsgiorg.user_data'], a real dictionary. If you want to move
that data over HTTP you have to serialize it to some header, but that
might be best to consider separately.

> 3. It might be possible that pylons will handle error 401 properly even
> without WWW-Authenticate header.

Pylons doesn't really care about WWW-Authenticate. But the HTTP spec
says that header is required with 401 responses.

It might be helpful with some cases where you really do want multiple
logins on a site, or where you don't want to clobber the login system
that some application might provide. An example where you have to be
trickier about logins is WebDAV -- they are in theory just web requests,
but the authentication available is more limited, and there are client
quirks you may want to work around.

Generally it's a somewhat open issue how to deal with different kinds of
clients, e.g., browsers and other automated clients (WebDAV, REST calls,
etc).

Ian

[Ross Vandegrift]

On Sat, Mar 29, 2008 at 04:23:31PM -0700, mdoudoroff wrote:
> It seems to me that AuthKit may have a few warts:
>
> 1) The "one group per user" limitation seems to be irritating people.
> I don't personally care, because all I need are roles, and I can't
> help but wonder if the people who are complaining about user groups
> really need the groups or if they're just confused about the
> distinction because the documentation is such a disaster.

Really? The AuthKit user/group/roles model is more or less parallel
to the traditional Unix model of permissions. I found it to be
completely natural.

--
Ross Vandegrift
ro...@kallisti.us

"The good Christian should beware of mathematicians, and all those who
make empty prophecies. The danger already exists that the mathematicians
have made a covenant with the devil to darken the spirit and to confine
man in the bonds of Hell."
--St. Augustine, De Genesi ad Litteram, Book II, xviii, 37

[Ross Vandegrift]

On Fri, Mar 28, 2008 at 10:19:35PM -0700, Mike Orr wrote:
> Their argument seems to be not that it doesn't work (the previous
> bugs have been fixed), but that you can write your own authentication
> in the time it takes to learn it. I haven't used AuthKit in a program
> so I can't say definitively one way or the other. As for the number
> of AuthKit discontents, it's impossible to say whether they're a
> substantial percentage of the Pylons userbase or a small number of
> loud activists.

I recently attempted to upgrade an existing application from an ad-hoc
authentication and authorization framework to AuthKit. In the end, I
decided my ad-hoc method was better. I'm not an AuthKit expert,
though I did give it a good try. Here were my reasons:

1) Bad documentation is worse than no documentation. Much of the
AuthKit documentation is out of date enough that it leads you down the
wrong path. The API reference are more useful than the examples, but
they are very difficult to follow, without being familiar with the
guts of AuthKit.

2) The only way I could determine to get style control over the login
screen (the "forward" method), was very complicated to implement. As
Mike said, complicated enough that I could write my own middleware to
do it in a similar amount of time.

3) What's worse is that I could never get "forward" authentication
working. The nice decorator syntax and uniform authorization API was
what I wanted, but I couldn't get to that point.

> AuthKit is probably most helpful if you have a complex permissions
> scheme and use the built-in plugins. It's less helpful if you use the
> "forward" feature to call back into the application for the login
> form. In that case you're doing most of the work yourself anyway and
> merely shoehorning it into AuthKit's API.

I agree with you 100% here, but I'll take it a step further.
Authkit's API is what's great about it. But who wants to choose
the barebones login screen it provides or an HTTP authentication
window? Is that really a common use case?

AuthKit's ability to express complex permissions for authorization is
really awesome, and it's where I see a lot of the value - the API is
very well considered. But getting an app with a custom login screen
converted over to it was enormously difficult.

> In that case you have to
> ask whether five lines of AuthKit API calls is really better than five
> lines of homegrown code. Probably not, and I think Gardner would
> agree here.

For complex permissions, this is a gross underestimate. My app
(though it could use some refactoring at this point) has hundreds of
lines for permissions between different roles and groups of users. It
includes LDAP interaction to get that data. It also has really ugly
hooks into the controllers to verify a user.

The object model of roles in AuthKit is the value - it's a lot like
RADIUS/TACACS+ if you're familiar with the router kind of AAA model.
I found that it wasn't trivially easy to reproduce that.

> I see that AuthKit does both,
> but I'm not sure how well it cascades from one to the other, or
> whether it will accept my existing Users table.

It does? I couldn't find any information on linking AuthKit with LDAP
(without writing my own objects to do it). And most of the
information I could find on using a database table seemed to be about
people unable to get it working. I had good luck with statically
configured users, but this doesn't scale.

In summary - it might just be a documentation issue. I really like
AuthKit's ideas. They seem very "correct" to me. It's just too
difficult to integrate into an app.

[Dalius Dobravolskas]

>> app = HTTPExceptionHandler(app)
>>
>> Example middleware:
>> http://hg.sandbox.lt/authform-middleware/file/2be2aba0a1b7/authform_middleware/authform.py
>
> Generally you shouldn't throw expected exceptions outside of your
> application. So HTTPExceptionHandler should be wrapping your
> controllers directly, and should translate any HTTPAuthorizationRequired
> exceptions into proper 401 responses. I don't think the auth middleware
> should wrap these itself.

Agreed. My mistake. That's the way AuthKit works but AuthKit is
authentication/authorization middleware (not only authentication).

>> 2. I think we should agree that user data if there is some data arriving
>> with authentication should be put into REMOTE_USER_DATA env. variable.
>> E.g. some SREG data comes with OpenID authentication and I put it into
>> dict converted to string ('{"nickname": "dalius"}') and later eval it so
>> it could be used. I'm not sure if data string must be agreed (e.g.
>> nickname, locale and etc) or leave that for authentication
>> plugin/middleware author to fix.
>
> evaling is generally a bad idea. You could consider it JSON or some
> more limited serialization of data. Or put it in, say,
> environ['x-wsgiorg.user_data'], a real dictionary.

This way is acceptable and enough for me. Not sure about others. Just
put that variable 'x-wsgiorg.user_data' in your specification.

Thank you for really complete answers.

Regards,
Dalius

[Dalius Dobravolskas]

Mike Orr wrote:
> OpenID is a new and different kind of authentication system, so I
> don't know if we've figured out the best way to integrate it yet.
> Feedback from those who use OpenID would be helpful.

You should use it to figure out. I accept any way where you can login
and are not asked to create internal account. I login therefore I'm your
user already. If I'm not then bye.

E.g. you can login using google account to youtube.com but you must
create youtube account after that anyway. A little big ugly but that's
not even the worst case.

AuthKit has more serious problem than figuring out how to use OpenID.
AuthKit's OpenID implementation is correct and it even works but it is
very painful to configure it and I miss some options. But I have
expressed my dissatisfaction about that already :-) That's why I offer
splitting AuthKit - while I believe I have already split it by showing
that it is possible to do.

Regards,
Dalius

[Chris Shenton]

"Mike Orr" <slugg...@gmail.com> writes:

> We need somebody who has used AuthKit to write the simple HOWTOs that
> people are asking for.

I did and did, but it was a while back and I suspect AuthKit's changed
since I wrote it:

http://pylonshq.com/project/pylonshq/wiki/PylonsWithAuthKitForward

I'm using it in a production app for a .gov and a .com client.

What bothered me most was that AuthKit wasn't something I could just
drop in and start using, with anything beyond the appname.conf file
supplying the username/password/groups.

I would hope that any sufficiently well-loved auth middleware would ship
with some working example apps that (say) stored to an
SQLite/MySQL/Postgresql DB, and LDAP/AD, and had user/group/role
management forms -- at least for Pylons. It bothered me to have to
write these myself, and know that everyone else did too; wasted effort
for lazy/efficient programmers.

Having said that, I did do an SQLite backend and management forms for
the .gov customer, then retrofitted it to get authentication info form a
RADIUS server since we use SecurID tokens and that's the easiest
protocol with which to communicate with the RSA server.

> Regarding auth, that has never been seen as a core Pylons
> responsibility. If you want a framework with a built-in auth library,
> see TurboGears.

I think this approach may scare a lot of people away from Pylons -- I
know I would have benefitted from a few more common tools being bundled.

> To answer another question in this thread, repoze is a set of
> WSGI-compatible libraries spun off from Zope. It's the most
> exciting contribution from Zope since ZODB, because it allows Zope
> products like Plone and other WSGI apps to be mixed in the same site.
> However, it's all brand new so it hasn't been fully evaluated which
> parts are most useful in Pylons apps. Again, we need feedback from
> people who try repoze.who.

At PyCon, I wrote a RADIUS authentication module for repoze.who (with
guidance from Chris McDonough). I don't understand the whole stack yet
but the approach seems rather good: the plugin was pretty easy to write
even tho I had never seen the repoze code before. It would be nice if I
could use repoze.who with Pylons, Zope, Grok, and Plone instead of
separate auth mechanisms for each.

[Mike Orr]

Opened ticket #403 for the outstanding AuthKit issues.

http://pylonshq.com/project/pylonshq/ticket/403

If I failed to list any issues, please add a comment to the ticket so
it doesn't get forgotten.

--
Mike Orr <slugg...@gmail.com>

[Dalius Dobravolskas]

Ian Bicking wrote:
> evaling is generally a bad idea. You could consider it JSON or some
> more limited serialization of data. Or put it in, say,
> environ['x-wsgiorg.user_data'], a real dictionary.

Paste complains if the real dictionary is placed in environ. Isn't that
too strict?

Regards,
Dalius

[Ian Bicking]

The WSGI spec only allows strings in ALL_CAPS keys. If you use a
lower-case dotted name for a key you can put anything in it.

Ian

[johnnyice]

I just finished setting up Pylons 0.9.6 with AuthKit and SQLAlchemy
0.4.4. I decided to write a tutorial that will hopefully serve to
help others and avoid the same hair pulling that I went through. =)

Hopefully it makes sense, as most of the files are the FULL file, not
snippets. Let me know what you guys think or if you have any
questions.

http://www.janisb.com/blog/2008/04/zero-to-60-with-pylons-in-just-minutes-part-1/


Hope that helps!

John


On Mar 29, 8:36 pm, "Mike Orr" <sluggos...@gmail.com> wrote:
> On Sat, Mar 29, 2008 at 4:23 PM, mdoudoroff <martin.doudor...@gmail.com> wrote:
> > Unfortunately, I can confirm that theAuthKitdocumentation situation

> > is appalling. I spent hours sifting through the obsolete "Pylonsbook"
> > chapters, their comments, the source code, and the cookbook documents

> > before gettingAuthKitrunning. The enraging thing is that afterwards
> > I realized that setting upAuthKitis actually quite easy! There's

> > relatively little to it! Yet the documentation turns it into this
> > monolithic, impenetrable thing. This is NO WAY to attract new users

> > (and eventual contributors) toPylons! Fundamental stuff like this has

> > to be fundamentally EASY, or people are going to look elsewhere.
>

> We need somebody who has usedAuthKitto write the simple HOWTOs that

> people are asking for. It sounds like you're qualified, if you're
> willing. The reason documentation is slow is that fewer people build
> authenticated sites than use SQLAlchemy/Genshi/forms, so there are a
> fewer number of people qualified to write auth documentation and to
> compare alternative auth libraries.
>
> The two chapters are part of a book that aims to be a complete

> reference ofPylonsprogramming, scaling to large sites. I guess they

> don't work as well outside that context. The complete book draft is
> supposedly going to be finished this week, so hopefully we'll have a
> copy online soon.
>

> The fact that James wrote bothAuthKitand the book, and would like to
> see both asPylons' standard, yet he responds to email sporadically

> (sometimes yes, sometimes no, sometimes a month later), has made it

> difficult to resolve the issues aroundAuthKit. This leaves the rest

> of us in a bit of a take-it-as-is-or-use-something-else situation.
>

> > It seems to me thatAuthKitmay have a few warts:

>
> > 1) The "one group per user" limitation seems to be irritating people.
> > I don't personally care, because all I need are roles, and I can't
> > help but wonder if the people who are complaining about user groups
> > really need the groups or if they're just confused about the
> > distinction because the documentation is such a disaster.
>
> Could be.
>
> > 2) Some of the authentication plug-ins may be under-developed. Some
> > people here are saying the OpenID stuff doesn't work very well. I
> > don't know a thing about it, but I see that OpenID is getting pretty
> > pervasive, so it will probably be increasingly critical to would-be
> > Pylonsadopters.
>
> OpenID is a new and different kind of authentication system, so I
> don't know if we've figured out the best way to integrate it yet.
> Feedback from those who use OpenID would be helpful.
>
> > 3) The options for how log-in screens are presented withAuthKitseem
> > too constricted or inelegant for some people.
>
> That may be.
>
>
>
> > I'm just starting to
> > look into this myself, but I have no opinion, yet. I will say that
> > it's something that should just happen "out of the box" and it should
> > be darn easy to customize.
>
> > That several different parties have initiated their own parallel

> > authentication kits forPylonswhile nobody can be bothered to put a
> > few hours into updating and completingAuthKit'sdocumentation is
> > really disconcerting. It does not say thatPylonsis a flexible
> > platform with a wealth of options. It saysPylonsis a fragmentary,

> > incomplete, incoherent platform that can only get you part of the way
> > there.
>
> > I'm a refugee from an old python framework--Webware for Python--that was
> > rife with derelict components from the get-go. It just looked
> > terrible. It was embarrassing. There were consequences: the community

> > waned far more than it waxed. I just got serious aboutPylons. I think

> > it does a lot of things right, apparently with much credit due Ian
> > Bicking. I apologize for dropping this rant into this thread, but I
> > want to emphasize how big a problem this is forPylons.
>
> I also started with Webware after being disilusioned with monolithic
> Zope. But I didn't like its servlet paradigm, borrowed from Java. Or
> its accessor methods or .camelCase. Webware also named its

> components *Kit, which makes me wishAuthKitwas called something

> else. Quixote seemed much more streamlined and minimalistic so I made
> several sites in that. But when WSGI came along I wanted something

> that was fully WSGI and modular down to the core, andPylonsis the
> only one of those.
>
> Pylonsaims to contain the most essential tools but does not make

> arbitrary choices about everything. So it includes Mako but also
> documents Genshi. It includes FormEncode/htmlfill/webhelpers but also
> documents ToscaWidgets and Django newforms. That's because we're not
> convinced that any of these form libraries are the "best" answer, but
> FormEncode/WebHelpers are an unobtrusive set of modular tools, so more

> in keeping with thePylonsphilosophy. Pylonshad built-in database

> support but found it couldn't keep up with the libraries, so it
> dropped that in favor of merely supporting SQLAlchemy in the

> documentation. Pylons0.9.7 offers a default SQLAlchemy model as a

> convenience, but you can take it or leave it.
>
> Regarding auth, that has never been seen as a corePylons
> responsibility. If you want a framework with a built-in auth library,
> see TurboGears. Nevertheless we want to support auth in the
> documentation, either withAuthKitalone orAuthKitplus
> alternatives.
>

> AsPylonshas partnered with TurboGears over the past six months, each

> has focused on its unique strengths. TG chooses a set of batteries

> for all aspects of web programming. Pylonsfocuses on a small set of

> essential tools, yet the documentation also shows how to integrate
> extra libraries. Generally we choose one library to recommend by
> default, yet try to show how to use the alternatives too, so users
> aren't reinventing the wheel from scratch. That has been one of my
> personal goals, which is why I've worled so much on the sQLAlchemy
> documentation even though SQLAlchemy is not aPylonsdependency.
>
> To answer another question in this thread, repoze is a set of
> WSGI-compatible libraries spun off from Zope. It's the most
> exciting contribution from Zope since ZODB, because it allows Zope
> products like Plone and other WSGI apps to be mixed in the same site.
> However, it's all brand new so it hasn't been fully evaluated which

> parts are most useful inPylonsapps. Again, we need feedback from

> people who try repoze.who.
>
> AuthKitwas written forPylons and uses thePylonsconfiguration

> system. Nobody has yet evaluated how to integrate repoze.who intoPylons' configuration, or whether it's worth it. I've heard praise
> forAuthKit'sauthorization but not for its authentication. Maybe the

> two will be split someday; that was part of my hope for the wiki page,
> that we'd pin down exactly what we need in an authentication system,

> and then make it easier forAuthKitto interoperate with other
> compliant systems. And simultaneously fill the gaps inAuthKit's
> documeentation and features to make it suitable asPylons' first

> recommendation, since it is the only one specifically built forPylons.
>
> Nobody has put any feedback on the wiki page yet. :( I renamed it so
> here's the current URL:http://wiki.pylonshq.com/pages/viewpage.action?pageId=11698714
>
> --

> Mike Orr <sluggos...@gmail.com>

[Eric Ongerth]

John, thanks for writing and sharing your Zero-to-Sixty. I read the
whole thing, and it makes Authkit look much easier to integrate and
get working than what the rumors seem to indicate I look forward to
reading part 3.

My one suggestion: your blog-format code windows are narrow and they
don't wrap lines. It looks like they're styled such that no matter
how wide I drag my browser window, they're still the same width, too.
Changing text size barely gets a few more characters visible in a
line, with many of the longer lines still invisible. Scrolling
(sometimes a page or more) down in the browser window in order to grab
a horizontal scrollbar at the foot of a code window kind of messes
with the continuity of the reading. Maybe you could style those code
sections differently or make the middle column of your blog
proportional to window width?

Eric

On Apr 16, 8:39 am, johnnyice <jjb...@gmail.com> wrote:
> I just finished setting up Pylons 0.9.6 with AuthKit and SQLAlchemy
> 0.4.4. I decided to write a tutorial that will hopefully serve to
> help others and avoid the same hair pulling that I went through. =)
>
> Hopefully it makes sense, as most of the files are the FULL file, not
> snippets. Let me know what you guys think or if you have any
> questions.
>

> http://www.janisb.com/blog/2008/04/zero-to-60-with-pylons-in-just-min...