Return-Path: Delivered-To: apmail-struts-user-archive@www.apache.org Received: (qmail 18017 invoked from network); 5 Feb 2006 18:59:36 -0000 Received: from hermes.apache.org (HELO mail.apache.org) (209.237.227.199) by minotaur.apache.org with SMTP; 5 Feb 2006 18:59:36 -0000 Received: (qmail 80845 invoked by uid 500); 5 Feb 2006 18:59:25 -0000 Delivered-To: apmail-struts-user-archive@struts.apache.org Received: (qmail 80808 invoked by uid 500); 5 Feb 2006 18:59:24 -0000 Mailing-List: contact user-help@struts.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Help: List-Post: List-Id: "Struts Users Mailing List" Reply-To: "Struts Users Mailing List" Delivered-To: mailing list user@struts.apache.org Received: (qmail 80797 invoked by uid 99); 5 Feb 2006 18:59:24 -0000 Received: from asf.osuosl.org (HELO asf.osuosl.org) (140.211.166.49) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 05 Feb 2006 10:59:24 -0800 X-ASF-Spam-Status: No, hits=-0.0 required=10.0 tests=SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (asf.osuosl.org: domain of jak-struts-user@m.gmane.org designates 80.91.229.2 as permitted sender) Received: from [80.91.229.2] (HELO ciao.gmane.org) (80.91.229.2) by apache.org (qpsmtpd/0.29) with ESMTP; Sun, 05 Feb 2006 10:59:23 -0800 Received: from list by ciao.gmane.org with local (Exim 4.43) id 1F5p67-00083I-KA for user@struts.apache.org; Sun, 05 Feb 2006 19:58:55 +0100 Received: from cpe00045ad20d9e-cm0011e6f60f1e.cpe.net.cable.rogers.com ([70.25.230.197]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 05 Feb 2006 19:58:55 +0100 Received: from laurie by cpe00045ad20d9e-cm0011e6f60f1e.cpe.net.cable.rogers.com with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 05 Feb 2006 19:58:55 +0100 X-Injected-Via-Gmane: http://gmane.org/ To: user@struts.apache.org From: Laurie Harper Subject: Re: HTTP BASIC authentication Date: Sun, 05 Feb 2006 13:58:45 -0500 Lines: 61 Message-ID: References: <20060205115517.44023.qmail@web50612.mail.yahoo.com> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: cpe00045ad20d9e-cm0011e6f60f1e.cpe.net.cable.rogers.com User-Agent: Thunderbird 1.5 (Macintosh/20051201) In-Reply-To: <20060205115517.44023.qmail@web50612.mail.yahoo.com> Sender: news X-Virus-Checked: Checked by ClamAV on apache.org X-Spam-Rating: minotaur.apache.org 1.6.2 0/1000/N As I said, HTTP doesn't have the idea of a session. To do what you want, you'd have to implement your own authentication layer rather than relying on the container. Hmm, come to think of it, form based container managed security may work close to the way you want. You might be able to bend that to your needs. L. Prashanth.S wrote: > Hello laurie, > You are right.. > Heres what i got from apache website..[see below] > > The confusion was because for some reason i was not able to see authorisation header[cached user credentials for subsequent requests] being sent from my browser client.. > > On a different note,is there any way wherein i can achieve what iam looking after??i.e establishing "authenticated session"??? > using security filters?? > OR is it a dangerous thing to do?? > > Many Thanks > Prashanth > > ================================== > How basic authentication works > When a particular resource has been protected using basic authentication, Apache sends a 401 Authentication Required header with the response to the request, in order to notify the client that user credentials must be supplied in order for the resource to be returned as requested. > Upon receiving a 401 response header, the client's browser, if it supports basic authentication, will ask the user to supply a username and password to be sent to the server. If you are using a graphical browser, such as Netscape or Internet Explorer, what you will see is a box which pops up and gives you a place to type in your username and password, to be sent back to the server. If the username is in the approved list, and if the password supplied is correct, the resource will be returned to the client. > Because the HTTP protocol is stateless, each request will be treated in the same way, even though they are from the same client. That is, every resource which is requested from the server will have to supply authentication credentials over again in order to receive the resource. > Fortunately, the browser takes care of the details here, so that you only have to type in your username and password one time per browser session - that is, you might have to type it in again the next time you open up your browser and visit the same web site. > Along with the 401 response, certain other information will be passed back to the client. In particular, it sends a name which is associated with the protected area of the web site. This is called the realm, or just the authentication name. The client browser caches the username and password that you supplied, and stores it along with the authentication realm, so that if other resources are requested from the same realm, the same username and password can be returned to authenticate that request without requiring the user to type them in again. This caching is usually just for the current browser session, but some browsers allow you to store them permanently, so that you never have to type in your password again. > The authentication name, or realm, will appear in the pop-up box, in order to identify what the username and password are being requested for. > > ======================================== > > > Laurie Harper wrote: > Prashanth.S wrote: >> Hello All, >> I have got a simple question on BASIC authentication on webresources using Tomcat. >> >> I had set up this BASIC authentication on tomcat and tomcat[because of my misconfiguration????] seems to authenticate user every time they accesses resource though the client is sending back the jsessionID cookie for session tracking... >> >> 2 request-response formats are as follows..Ideally i dont expect it to throw me an unauthorized error for the 2nd request..Can anyone point out what am i doing wrong?? > > You're not sending the Authorization header in the second request. > Remember, HTTP is stateless. Sessions are a web-app thing and have > nothing to do with HTTP authentication. Sending a session cookie has no > effect on HTTP authentication. > > L. > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org > For additional commands, e-mail: user-help@struts.apache.org > > > > > --------------------------------- > Do you Yahoo!? > New and Improved Yahoo! Mail - 1GB free storage! --------------------------------------------------------------------- To unsubscribe, e-mail: user-unsubscribe@struts.apache.org For additional commands, e-mail: user-help@struts.apache.org