Re: [Mailman-Developers] cookies
[Ricardo Kustner]
Hi,
this was just suggested to me by somebody from mailman-users:
Please write a patch which puts the string "Cookie could not be set" on the web page so that I can see that pressing submit will not work :-)
i think thats a good point... it would safe some user questions if MM tells exactly why the authorisation failed.
While I agree that such a warning would be nice, I don't think it's possible to do such things with cookies.
I'm not sure if this subject has been touched already, but what allowing admins to choose between cookies and Basic-Authorization... it should be possible to use Basic-auth, right?
What is Basic-Authorization? If it doesn't involve a HTTP POST of the admin login page, I believe it will not work (out of the box, anyway).
Harald
Hi,
On Tue, May 09, 2000 at 09:12:49PM +0200, Harald Meland wrote:
Please write a patch which puts the string "Cookie could not be set" on the web page so that I can see that pressing submit will not work :-) i think thats a good point... it would safe some user questions if MM tells exactly why the authorisation failed. While I agree that such a warning would be nice, I don't think it's possible to do such things with cookies. it's possible to set a test cookie to see if cookies are enabled...(and writing a "your browser doesn't allow / can't set cookies" warning if it fails)... if the test is OK but the authorisation failed, an authorization error could be printed. or am i missing the point? :)
I'm not sure if this subject has been touched already, but what allowing admins to choose between cookies and Basic-Authorization... it should be possible to use Basic-auth, right? What is Basic-Authorization? If it doesn't involve a HTTP POST of the admin login page, I believe it will not work (out of the box, anyway). Basic-auth is a cgi process sending an 401 auth required http header and thus asking the browser to prompt for a username and password... I'm not 100% sure if it's possible with a cgi script though (I know it's possible in PHP but I've never tried it in cgi...)
Ricardo.
--
On Wed, May 10, 2000 at 01:08:22AM +0200, Ricardo Kustner wrote:
What is Basic-Authorization? If it doesn't involve a HTTP POST of the admin login page, I believe it will not work (out of the box, anyway).
Basic-auth is a cgi process sending an 401 auth required http header and thus asking the browser to prompt for a username and password... I'm not 100% sure if it's possible with a cgi script though (I know it's possible in PHP but I've never tried it in cgi...)
Basic auth is possible in CGI; you just have to make sure your webserver allows you to send HTTP response codes. If I recall correctly, you can do this in Apache by naming your script 'nph-<script>', but given the fast development cycle of Apache and other webservers, there might be a better, more portable way. After the server sends a 401, the browser resends the request with an aditional header, 'Authorization', with the value 'Basic <secret>', where <secret> is 'username:password' base64-encoded.
I'm not sure if basic auth would suite Mailmans' needs. There might be some issues regarding length of username, and wether it can contain an @, for instance. (IE, and perhaps Netscape too, nowadays, allow you to specify username and password in the URL: http://user:password@server/. This would probably barf when faced with @s in usernames or passwords. I also dont know if this is in the RFC.) Also, basic auth behaves differently from Cookies: they are hostname+path-based instead of just hostname-based, and they expire when the browser closes or another '401 auth required' occurs. You can try to force an expire by sending back a 401 auth required as 'logout', but this tends to confuse a lot of people, because they usually get another popup window asking for a username/password ;P
Basic auth works with all HTTP requests, though, and I believe has more support than cookies. (httplib has auth support, I use it frequently. Does it have cookie support ? :)
-- Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
"TW" == Thomas Wouters <thomas@xs4all.net> writes:
TW> Also, basic auth behaves differently from Cookies: they are
TW> hostname+path-based instead of just hostname-based, and they
TW> expire when the browser closes or another '401 auth required'
TW> occurs.Jitterbug uses this and it sucks. If I have 3 different Jitterbug projects on the same host, every time I authenticate to one, I lose the authentication to the other. This loss is persistent across sessions.
Now, maybe I don't have Jitterbug set up correctly, or maybe they have bugs in their implementation, but I would hate it if Mailman worked the same way.
I've been playing with SourceForge a lot lately[1] and I like what they do. You login with username/password over a secure link and once logged in, your primary interaction is across that link. Seems intuitive, secure, and convenient. This is the direction I think I'd like to go in.
-Barry
[1] In preparation for moving Mailman development over to SF!
On Wed, May 10, 2000 at 09:33:32AM -0400, bwarsaw@python.org wrote:
TW> Also, basic auth behaves differently from Cookies: they are TW> hostname+path-based instead of just hostname-based, and they TW> expire when the browser closes or another '401 auth required' TW> occurs.
Jitterbug uses this and it sucks. If I have 3 different Jitterbug projects on the same host, every time I authenticate to one, I lose the authentication to the other. This loss is persistent across sessions.
Oh, I agree completely. Our IMP-based webmail servers still use the http auth method, though the newer IMPs changed to cookie-based auth. A huge improvement, for sure ;)
I've been playing with SourceForge a lot lately[1] and I like what they do. You login with username/password over a secure link and once logged in, your primary interaction is across that link. Seems intuitive, secure, and convenient. This is the direction I think I'd like to go in.
Hm, I'm not sure how this would work. You log in once through SSL and your ipaddress gets stored in a temporary access list ? Or does it use some kind of persistant connection ? SSH + port forwarding ?
-- Thomas Wouters <thomas@xs4all.net>
Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
"TW" == Thomas Wouters <thomas@xs4all.net> writes:
>> I've been playing with SourceForge a lot lately[1] and I like
>> what they do. You login with username/password over a secure
>> link and once logged in, your primary interaction is across
>> that link. Seems intuitive, secure, and convenient. This is
>> the direction I think I'd like to go in.
TW> Hm, I'm not sure how this would work. You log in once through
TW> SSL and your ipaddress gets stored in a temporary access list
TW> ? Or does it use some kind of persistant connection ? SSH +
TW> port forwarding ?I think it's simpler than that. The login screen is an https URL, so presumably your password is sent over encrypted. They do drop a cookie on you, so nothing's different there, but (almost) every URL you hit from there on out is an https.
Coffee taking effect now, maybe the only thing that's different is that the login happens over https, which, given that we're emailing plaintext password reminders, probably isn't such a big deal.
On the other hand, they way SF /seems/ to handle lost passwords is that they email your account with a URL you can use to change your password and login. I say seems, 'cause I didn't actually try it out (don't want to invalidate my password :). Since password reminders gets a fair number of negative responses both from admins and users, this might be a more reasonable approach to take once we have a RUD (Real User Database).
-Barry
participants (4)
-
bwarsaw＠python.org -
Harald Meland -
Ricardo Kustner -
Thomas Wouters