<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Jan 21, 2013 at 11:05 AM, Chris Cunnington <span dir="ltr"><<a href="mailto:smalltalktelevision@gmail.com" target="_blank">smalltalktelevision@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">So, near as I can figure it, auth in AL2.0 works something like this [1].<br>
<br>
I was wondering what was happening to the Relays. They were disappearing.<br>
It seems to me that they are added to an ALApplication with #addFactory:.<br></blockquote><div><br></div><div>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).</div>
<div><br></div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
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?<br>
</blockquote><div><br></div><div>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). </div>
<div><br></div><div>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.)</div>
<div><br></div><div>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.</div>
<div><br></div><div>Colin</div><div><br></div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
An authentication addition to AL-Examples-Simple would be great.<br>
<br>
Chris<br>
<br>
[1]<br>
<br>
cache := ALMemoryAuthenticator new.<br>
cache register: 1 username: 'griffle' password: 'plonk'.<br>
cache<br>
<br>
authRelay := ALAuthenticationRelay destination: foo<br>
authenticator: cache<br>
shunt: footwo<br>
<br>
app := ALExampleApplication new.<br>
app addFactory: authRelay.<br>
<br>
<br>
(ALServer on: 8624 application: app)<br>
<br>
</blockquote></div><br></div></div>