[Seaside] BUG: Basic authentication

[radoslav hodnicak]

Ok since I got asked how to do it, here is a simple how-to. This is also 
the way to implement "logout" with basic auth.

Create your own Main Class subclass (you set that in entry point 
configuration) if you don't have it already, and add instance
variable that will store the info whether it was the first auth attempt. 
Then use the variable in YourMainClass>>verifyPassword:forUser:

verifyPassword: pass fromUser: user

  isFirstAuth ifTrue: [isFirstAuth := false. ^false].
  ^super verifyPassword: pass fromUser: user.

You also need to force a redirect on a new session, so that the session 
key is inserted into URL and you get the same session again on subsequent 
requests (otherwise a new session is created for every request and the 
above code never gets past the first auth check). In YourMainClass>>start 
change the creation of render loop like this

start: aRequest
   (WARenderLoop new root: self createRoot) redirect; run


Doc/faq people - please add this to the cookbook

rado

On Wed, 31 Aug 2005, radoslav hodnicak wrote:

>
> I use basic auth because it's a simple way to
>
> a) prevent url hijacking (when someone "steals" url from other 
> computer/browser and tries it on own computer - he gets login prompt)
>
> b) log to see what the user sees - if someone is having problems I tell them 
> to send me the url from their browser and I log in using my admin password
>
> c) allow users to have browsers store the login info for them - this isn't 
> big issue now, but was with seaside 2.3, the browsers would not store login 
> info from input fields because of the ever changing url
>
> To solve the issue with reusing login/passwd with different realms, I just 
> reject the first auth request in a new session, even if the login information 
> is correct. The browser will then display the login prompt
>
> rado
>
> On Wed, 31 Aug 2005, Julian Fitzell wrote:
>
>> Ok, I take it back... I *can* reproduce this.  Hmm...
>> 
>> It seems that the browsers are trying to help out the user by trying the
>> stored credentials even though the realm doesn't match.  One could argue 
>> that
>> this is a valid thing to do, but since it could expose the password to 
>> another
>> app running on the same machine, I can see why it might not be desired.
>> Perhaps someone else on the list can suggest something, but off the top of 
>> my
>> head I can't see how to prevent browsers from behaving this way (short of
>> serving each of your apps from a different domain, which I imagine--hope!--
>> would work).
>> 
>> Otherwise... I suggest not using Basic Auth if this is a problem for you.
>> When you have session state anyway, there's really no advantage to using it
>> that I can see.  We really should have a bundled authentication mechanism 
>> that
>> doesn't use basic auth...
>> 
>> Julian
>> 
>> Quoting Mart-Mari Breedt <breedt_m at aircom.co.za>:
>> 
>>> Thank you for your reply.
>>> 
>>> We are using Seaside 2.6a2, but the problem also occurs in Seaside
>>> 2.6a1.
>>> 
>>> I added WAAuthConfiguration to the basic counter application and created
>>> a second entry point to the counter application (counter2) and added
>>> WAAuthConfiguartion to it as well. I specified the username and password
>>> as being admin and seaside respectively on both.
>>> 
>>> I tried accessing the application from different browsers, but I get the
>>> same behavior in Firefox, Opera and IE. The user is prompted for a
>>> password when the first entry point is accessed, but the user is
>>> definitely not prompted when trying to access the second entry point.
>>> 
>>> I can see the realms are indeed different for each entry point since the
>>> realm is displayed when prompted for a password. I.e. when I access the
>>> entry points in a reversed order from a new browser session I can see
>>> the counter2 realm is different to the counter realm.
>>> 
>>> Thank you,
>>> Mart-Mari
>>> 
>>> -----Original Message-----
>>> From: Julian Fitzell [mailto:julian at beta4.com]
>>> Sent: 31 Augustus 2005 04:40
>>> To: The Squeak Enterprise Aubergines Server - general discussion.
>>> Subject: Re: [Seaside] BUG: Basic authentication
>>> 
>>> Hmm... I can't reproduce this obviously with Seaside 2.5.
>>> 
>>> The two applications obviously have different basePath's and it is the
>>> basePath that Seaside uses by default as the realm for HTTP Basic
>>> Authentication.  As long as the applications are providing different
>>> authentication realms, the user should be reprompted for a password.  If
>>> this
>>> is not the case, this is obviously a browser bug.
>>> 
>>> Can you confirm which version of seaside you're using and perhaps how
>>> you are
>>> setting up the authenticated applications... is there any reason they
>>> would
>>> actually be using the same realm?
>>> 
>>> Julian
>>> 
>>> Quoting Mart-Mari Breedt <breedt_m at aircom.co.za>:
>>> 
>>>> Hallo all,
>>>> 
>>>> 
>>>> 
>>>> We have the following problem. Consider you have two instances of the
>>>> same seaside application, each set up with basic authentication.
>>>> Example, you have two instances of the counter application (named
>>>> counter1 and counter2) with username=admin and password=seaside on
>>> both.
>>>> 
>>>> 
>>>> 
>>>> 
>>>> When you log on to seaside/counter1, you would be prompted for a
>>>> username and password. (Which is correct...) When you now log on to
>>>> seaside/counter2 (from the same browser session) you would NOT be
>>>> prompted for a username and password. The WARequest object contains
>>> the
>>>> previous username and password and since it is the same as the
>>> username
>>>> and password for this application, you are automatically validated.
>>> This
>>>> (We believe) is a bug, since you should have been prompted for a new
>>>> username and password for two reasons. One: Because you are starting a
>>>> new session and Two: Because you are accessing a totally different
>>>> application instance.
>>>> 
>>>> 
>>>> 
>>>> Does anyone have any ideas or previous experiences on fixing this?
>>>> 
>>>> 
>>>> 
>>>> Thank you,
>>>> 
>>>> 
>>>> 
>>>> Mart-Mari
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>>> 
>>> 
>>> 
>>> --
>>> julian at beta4.com
>>> Beta4 Productions (http://www.beta4.com)
>>> _______________________________________________
>>> Seaside mailing list
>>> Seaside at lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/listinfo/seaside
>>> 
>>> _______________________________________________
>>> Seaside mailing list
>>> Seaside at lists.squeakfoundation.org
>>> http://lists.squeakfoundation.org/listinfo/seaside
>>> 
>> 
>> 
>> -- 
>> julian at beta4.com
>> Beta4 Productions (http://www.beta4.com)
>> _______________________________________________
>> Seaside mailing list
>> Seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/listinfo/seaside
>> 
> _______________________________________________
> Seaside mailing list
> Seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/listinfo/seaside
>