Smalltalk › Squeak › Squeak - Dev

AL2.0 - authentication

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

2 messages Options

Chris Cunnington

AL2.0 - authentication

So, near as I can figure it, auth in AL2.0 works something like this [1].

I was wondering what was happening to the Relays. They were disappearing.
It seems to me that they are added to an ALApplication with #addFactory:.

The nifty part looks to be that relays are activated by Notifications.
The Relay contacts the cache of passwords by means of a Notification. If
the username/password passes, then the flow of the program is not
blocked, and it proceeds to ALTerminalRelay. No?

An authentication addition to AL-Examples-Simple would be great.

Chris

[1]

cache := ALMemoryAuthenticator new.
cache register: 1 username: 'griffle' password: 'plonk'.
cache

authRelay := ALAuthenticationRelay destination: foo
authenticator: cache
shunt: footwo

app := ALExampleApplication new.
app addFactory: authRelay.

(ALServer on: 8624 application: app)

Colin Putney-3

Re: AL2.0 - authentication

On Mon, Jan 21, 2013 at 11:05 AM, Chris Cunnington <[hidden email]> wrote:

So, near as I can figure it, auth in AL2.0 works something like this [1].

I was wondering what was happening to the Relays. They were disappearing.
It seems to me that they are added to an ALApplication with #addFactory:.

Yeah, I was folding a lot of relays into the main HTTP framework, because they were doing things that didn't need to be configurable. (Eg, setting required headers, or ensuring that the HTTP body is encoded the way the headers say it is).

Also, a new relay pipeline is built for each request, which simplifies relay implementation. #addFactory: takes a block that creates a relay, not a relay its self.

The nifty part looks to be that relays are activated by Notifications. The Relay contacts the cache of passwords by means of a Notification. If the username/password passes, then the flow of the program is not blocked, and it proceeds to ALTerminalRelay. No?

Yes. The idea is that relays are part of the dynamic scope during dispatch and rendering, so other parts of the application can use Notifications to communicate with them. Also, they can catch and handle exceptions (eg. ALHttpExceptionRelay).

For auth, a resource or component can throw ALUserStipulation which requests that ALAuthenticationRelay verify that the specified user is logged in. The relay examines the request for the auth cookie, verifies the cookie with an authenticator, and if all is well, resumes the exception. If the auth cookie is absent, or doesn't match the specified user, the relay shunts the request to a special handler which can answer a 403 response or redirect to a login form or whatever. (In your example below, "footwo" should be a block.)

Right now, the only authenticator is ALMemoryAuthenticator, which just stores usernames and passwords in dictionaries. But the idea is to implement bindings to external services, which could store things in a database, do LDAP lookups, OAuth or whatever.

Colin

An authentication addition to AL-Examples-Simple would be great.

Chris

[1]

cache := ALMemoryAuthenticator new.
cache register: 1 username: 'griffle' password: 'plonk'.
cache

authRelay := ALAuthenticationRelay destination: foo
authenticator: cache
shunt: footwo

app := ALExampleApplication new.
app addFactory: authRelay.

(ALServer on: 8624 application: app)