New AuthResource

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
5 messages Options
Reply | Threaded
Open this post in threaded view
|

New AuthResource

Ken Treis-4
I realized something the other day while playing with my new customer's
site.  The way the ACLResource is written, it expects you to build
something like this:

<ACLResource stringUriPattern: 'auth' ...>
  <FileResource stringUriPattern: 'files' ...>

Then, the URI for access-controlled files would be "auth/files/".  If
you weren't authorized, it'd ask you to login.  If you were, it'd just
give the files to you.

The only problem was this: the first access after login would always be
done with a POST.  If any subsequent requests took them off the page and
they wanted to use the browser's back button to get back, the browser
would ask them if they wanted to re-post the form data.

The way this is normally dealt with is to have the successful login
redirect the user to the files area.  So the uri for authorized files
now looks like "auth", and it redirects you to "auth/files/" after you
click the Login button.

This is why I added the "found" response type (see previous message);
it's the only one that works consistently across browsers for these
types of redirects.

My customer was also a bit concerned when, in the former scenario, the
"authorized area" link would only sometimes ask him for a login and
password.  He wasn't aware of the architecture, so the behavior confused
him.  This new scenario makes more sense to the end user.

To support this in an ACLResource (or any generic AuthResource), I had
to add one more creation parameter: the target URI for redirection.  So
now, you make an AuthResource with something like this:

<ACLResource stringUriPattern: 'admin' targetUri: '/admin/home/'
listFile: 'admin.acl'>

Attached is a parcel that has the new code.

----

As an aside, where is everybody else?  Joe/David/Janko/Benny, are you
swamped with other stuff?  Jerry has gotten back to me on these (and I
think he has them working in Dolphin already); I've been releasing these
add-ons as parcels so as to allow for the integration of whatever it was
that Benny and Janko did at CS@OOPSLA.  Joe, if you need, I can
integrate that stuff.  Then, we can get to work on some bigger things
(our URI resolution is bothering me again, cross-platform stuff, etc).


Ken Treis
[hidden email]

authResource.zip (6K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

RE: New AuthResource

Jerry Bell
I've actually had Swazoo for Dolphin up to the current VW sources on
SourceForge for a week or so, but I haven't packaged them up yet.


I'll add these changes and package everything up tonight.

Jerry
[hidden email]

> -----Original Message-----
> From: [hidden email]
> [mailto:[hidden email]]On Behalf Of
> Ken Treis
> Sent: Monday, December 04, 2000 12:54 AM
> To: [hidden email]
> Subject: [Swazoo-devel] New AuthResource
>
>
> I realized something the other day while playing with my new
> customer's
> site.  The way the ACLResource is written, it expects you to build
> something like this:
>
> <ACLResource stringUriPattern: 'auth' ...>
>   <FileResource stringUriPattern: 'files' ...>
>
> Then, the URI for access-controlled files would be "auth/files/".  If
> you weren't authorized, it'd ask you to login.  If you were,
> it'd just
> give the files to you.
>
> The only problem was this: the first access after login would
> always be
> done with a POST.  If any subsequent requests took them off
> the page and
> they wanted to use the browser's back button to get back, the browser
> would ask them if they wanted to re-post the form data.
>
> The way this is normally dealt with is to have the successful login
> redirect the user to the files area.  So the uri for authorized files
> now looks like "auth", and it redirects you to "auth/files/"
> after you
> click the Login button.
>
> This is why I added the "found" response type (see previous message);
> it's the only one that works consistently across browsers for these
> types of redirects.
>
> My customer was also a bit concerned when, in the former
> scenario, the
> "authorized area" link would only sometimes ask him for a login and
> password.  He wasn't aware of the architecture, so the
> behavior confused
> him.  This new scenario makes more sense to the end user.
>
> To support this in an ACLResource (or any generic
> AuthResource), I had
> to add one more creation parameter: the target URI for
> redirection.  So
> now, you make an AuthResource with something like this:
>
> <ACLResource stringUriPattern: 'admin' targetUri: '/admin/home/'
> listFile: 'admin.acl'>
>
> Attached is a parcel that has the new code.
>
> ----
>
> As an aside, where is everybody else?  Joe/David/Janko/Benny, are you
> swamped with other stuff?  Jerry has gotten back to me on
> these (and I
> think he has them working in Dolphin already); I've been
> releasing these
> add-ons as parcels so as to allow for the integration of
> whatever it was
> that Benny and Janko did at CS@OOPSLA.  Joe, if you need, I can
> integrate that stuff.  Then, we can get to work on some bigger things
> (our URI resolution is bothering me again, cross-platform stuff, etc).
>
>
> Ken Treis
> [hidden email]
>


Reply | Threaded
Open this post in threaded view
|

Re: New AuthResource

Joseph Bacanskas-2
In reply to this post by Ken Treis-4
Hi:

Swamped is an understatement. :-(

Ken:  I will FULLY review this stuff over the weekend and post my comments.  It
sounds to me like you are on the right track.  As to integrating Janko's OOPSLA
stuff, I probably do need you to take that on since Swazoo has moved ahead of me
more than I expected.  I'll send you the code this Friday, I'm in Beaverton at
GemStone until Thursday night.  After this weekend, I expect to be much more
involved again.

BTW - Has anyone seen any posts from Charles Montiero?  I got an email from him
last week saying that he has a basic JSP-like resource he build in Swazoo and
wants to extend it after he gets the session resource stuff.

Ken Treis wrote:

> I realized something the other day while playing with my new customer's
> site.  The way the ACLResource is written, it expects you to build
> something like this:
>
> <ACLResource stringUriPattern: 'auth' ...>
>   <FileResource stringUriPattern: 'files' ...>
>
> Then, the URI for access-controlled files would be "auth/files/".  If
> you weren't authorized, it'd ask you to login.  If you were, it'd just
> give the files to you.
>
> The only problem was this: the first access after login would always be
> done with a POST.  If any subsequent requests took them off the page and
> they wanted to use the browser's back button to get back, the browser
> would ask them if they wanted to re-post the form data.
>
> The way this is normally dealt with is to have the successful login
> redirect the user to the files area.  So the uri for authorized files
> now looks like "auth", and it redirects you to "auth/files/" after you
> click the Login button.
>
> This is why I added the "found" response type (see previous message);
> it's the only one that works consistently across browsers for these
> types of redirects.
>
> My customer was also a bit concerned when, in the former scenario, the
> "authorized area" link would only sometimes ask him for a login and
> password.  He wasn't aware of the architecture, so the behavior confused
> him.  This new scenario makes more sense to the end user.
>
> To support this in an ACLResource (or any generic AuthResource), I had
> to add one more creation parameter: the target URI for redirection.  So
> now, you make an AuthResource with something like this:
>
> <ACLResource stringUriPattern: 'admin' targetUri: '/admin/home/'
> listFile: 'admin.acl'>
>
> Attached is a parcel that has the new code.
>
> ----
>
> As an aside, where is everybody else?  Joe/David/Janko/Benny, are you
> swamped with other stuff?  Jerry has gotten back to me on these (and I
> think he has them working in Dolphin already); I've been releasing these
> add-ons as parcels so as to allow for the integration of whatever it was
> that Benny and Janko did at CS@OOPSLA.  Joe, if you need, I can
> integrate that stuff.  Then, we can get to work on some bigger things
> (our URI resolution is bothering me again, cross-platform stuff, etc).
>
> Ken Treis
> [hidden email]
>
>   ------------------------------------------------------------------------
>                        Name: authResource.zip
>    authResource.zip    Type: Zip Compressed Data (application/x-zip-compressed)
>                    Encoding: base64

--
Thanks!!

Joseph Bacanskas [|]
Software Engineer, Smalltalk
GemStone Systems, Inc. - a Brokat company




Reply | Threaded
Open this post in threaded view
|

Re: Where I am (was New AuthResource)

Janko Mivšek
In reply to this post by Ken Treis-4
Hi Ken,

Ken Treis wrote:

> ....

> As an aside, where is everybody else?  Joe/David/Janko/Benny, are you
> swamped with other stuff?  Jerry has gotten back to me on these (and I
> think he has them working in Dolphin already); I've been releasing these
> add-ons as parcels so as to allow for the integration of whatever it was
> that Benny and Janko did at CS@OOPSLA.  Joe, if you need, I can
> integrate that stuff.  Then, we can get to work on some bigger things
> (our URI resolution is bothering me again, cross-platform stuff, etc).

Yes, I am deeply in one new project, which must be finished
to the end of a year. Therefore, no time for Swazoo until
January ...

But we will need SSL stuff somewhere in Jan or Feb and then
I willl be back in Swazoo again. It's my plan to put SSL in
Swazoo and replace AIDA Web server part with Swazoo at that
moment. And Swazoo will be live instantly on about 10 more
systems :)

Ken, I'm following your work as much as my time allows and
it seems to me, that you are going in right direction and
that we will be able to combine ideas about
security/authentication/access control in near future. I
must also take care about backward compatibility of new
security with current AIDA stuff (a lot of live AIDAs around
:) but so far I don't see a problem here.

Maybe some info about a new project we are doing here. It's
called e-logis, e-commerce and logistics combined :)
Currently I'm working on a general model for logistics,
which will cover warehousing and transport. And with
e-commerce with XML/SOAP, e-logis systems will be tightly
connected into a "logistic web" ...

I must tell that this project really impressed me, it's very
attractive and therefore all my time goes in it :)

And of course, e-logis is completly web based, will use
Swazzo and AIDA as the web app engine, on Gemstone ODB,
later probably on OmniBase for smaller systems :)

That's for now, more later

Have a nice time!
Janko

--
Janko Mivsek
Systems Architect
EraNova d.o.o.
Pod hribom 55
SI-1000 Ljubljana
Slovenia
phone: +386 1 5816 232
fax: +386 1 5816 231
[hidden email]
www.eranova.si

Reply | Threaded
Open this post in threaded view
|

Re: New AuthResource

Ken Treis-4
In reply to this post by Joseph Bacanskas-2
Joseph Bacanskas wrote:

> Hi:
>
> Swamped is an understatement. :-(
>
> Ken:  I will FULLY review this stuff over the weekend and post my comments.  It
> sounds to me like you are on the right track.  As to integrating Janko's OOPSLA
> stuff, I probably do need you to take that on since Swazoo has moved ahead of me
> more than I expected.  I'll send you the code this Friday, I'm in Beaverton at
> GemStone until Thursday night.  After this weekend, I expect to be much more
> involved again.

Good.  I'll have a look at it soon, and I'll start integrating things
then -- unless I hear major objections.

> BTW - Has anyone seen any posts from Charles Montiero?  I got an email from him
> last week saying that he has a basic JSP-like resource he build in Swazoo and
> wants to extend it after he gets the session resource stuff

Not here on this list -- but it sounds cool.  I have been thinking about
something similar, so I'm excited to see what he's done.  Has he
subscribed to the list?


--
Ken Treis
[hidden email]