If you've already implemented your own access control, then certainly it
might be more feasible to extend that to this set of pages.  A filter
might be the best, if you can use a 2.3 compliant container.
 
The filter would simply check for the presence of a session.  If there
isn't one, sendRedirect() to a login page.  Else, the filter will just
'pass through' the request. The filter can  be mapped to any requests
for  /downloaddir/* 

> -----Original Message-----
> From: Robert Priest [mailto:[EMAIL PROTECTED] 
> Sent: Monday, July 28, 2003 11:46 AM
> To: 'Tomcat Users List'
> Subject: RE: Session\Security Checking
> 
> 
> But I still need to change how my user are authenticated, 
> correct. I now need to handle that authentication through the 
> realm instead of a Form on our page now, right?
> 
> -----Original Message-----
> From: Mike Curwen [mailto:[EMAIL PROTECTED]
> Sent: Monday, July 28, 2003 12:33 PM
> To: 'Tomcat Users List'
> Subject: RE: Session\Security Checking
> 
> 
> I think using a realm and simply setting up /downloaddir/* as 
> a 'protected resource' is the way to go.  The functionality 
> you're looking for has already been implemented by 
> Container-Managed Auth.
>  
> Also.. if you use a container AUTH scheme, then you don't 
> need the Session ID in the URL.  The mere presence of a 
> session will prove that your user is "logged in and authenticated".
> 
> 
> > -----Original Message-----
> > From: Robert Priest [mailto:[EMAIL PROTECTED]
> > Sent: Monday, July 28, 2003 11:25 AM
> > To: 'Tomcat Users List'
> > Subject: RE: Session\Security Checking
> > 
> > 
> > thanks, rick. I appreciate the info. But I am not sure that
> > we want to use realm for our solution. But I certainly think 
> > it is feasible. 
> > 
> > I think we are more in the market for some sort of simple
> > session guard. Please allow me to explain a little further. 
> > Then I would like to hear your opinion about the suggested 
> > approach versus adding a REALM:
> > 
> > the URL for the download will contain a session id for the
> > user. So if you will allow me to modify my example:
> > 
> > Say user A logs in and has a session id of "1" and wants to
> > download abc.jar. He will be redirected to the url: 
> > http://localhost/myservlet/downloaddir/1/abc.jar
> > 
> > now I would like to put in place a guard servlet. So in
> > myservlet's web.xml I will add 
> > 
> > <servlet-mapping>
> >     <servlet-name>com.myproj.web.GUARD</servlet-name>
> >     <url-pattern>/downloaddir/*</url-pattern>
> > </servlet-mapping>
> > 
> > The intention is for the "Guard" servlet to:
> > 
> > 1. Inspect the url for sessionid ("1" in this case").
> > 2. Get it and compare it to the current session id
> > (session.getID()). 3. if the two match, then start an http 
> > download. 4. If not then, throw up an "Access Denied" error page.
> > 
> > That is pretty much all we need to do. I also don't want to
> > add basic\Form authentication at this point for those 
> > directories. We simply want to match whether the session id 
> > in the url is the same as the one the current user is using.
> > 
> > That way, if another user, who will have a different session
> > number (3 or what have you) tries to paste in:  
> > 
> >  http://localhost/myservlet/downloaddir/1/abc.jar
> > 
> > he\she will get an access denied.
> > 
> > Is that more understandable?
> > 
> > We are trying to prevent cutting and pasting of urls.
> > 
> > We are mainly concerned with just providing\denying access to
> > this directory and not security to an entire web application 
> > where I think the REALM would be more applicable (i am not 
> > sure whether that is right or wrong...).
> > 
> > 
> > -----Original Message-----
> > From: Rick Roberts [mailto:[EMAIL PROTECTED]
> > Sent: Monday, July 28, 2003 12:09 PM
> > To: Tomcat Users List
> > Subject: Re: Session\Security Checking
> > 
> > 
> > Found a link for ya:
> > http://jakarta.apache.org/tomcat/tomcat-4.1-doc/realm-howto.html
> > 
> > Rick
> > 
> > Robert Priest wrote:
> > > How can I check for a Valid session id before allowing access to a
> > > file?
> > > 
> > > For example:
> > > 
> > > - I have a directory containing files for download:
> > > http://localhost/myservlet/downloaddir/
> > > - but before you download a file, say abc.jar (by using 
> > > "http://localhost/myservlet/downloaddir/abc.jar";), I want 
> > to make sure
> > that
> > > you have a valid session id. If your
> > > session id is invalid, you get an access denied page. if
> > not, a http
> > > download is started.
> > > 
> > > so I guess what I want is to intercept any request to that
> > > "downloaddir" and perform session\security checking (by another 
> > > servlet or jsp page) before allowing access...
> > > 
> > > 
> > > Now, is adding additional servlet\jsp the best way to go
> > about this,
> > > or is there a better way through Tomcat configuration?
> > > 
> > > 
> > > Thanks.
> > > 
> > > 
> > > 
> > 
> ---------------------------------------------------------------------
> > > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > > For additional commands, e-mail: 
> [EMAIL PROTECTED]
> > > 
> > 
> > --
> > *******************************************
> > * Rick Roberts                            *
> > * Advanced Information Technologies, Inc. *
> > *******************************************
> > 
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> > 
> ---------------------------------------------------------------------
> > To unsubscribe, e-mail: [EMAIL PROTECTED]
> > For additional commands, e-mail: [EMAIL PROTECTED]
> > 
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Reply via email to