Re: multiuser setup: please help

2003-06-30 Thread ben . jessel
If you're looking for another option, download the eclipse IDE ( 
http://www.eclipse.org ) and use the tomcat plug in  
www.sysdeo.com/eclipse/tomcatPlugin.html.This will give you a totally 
integrated IDE and App Server environment, and you're not stuck waiting 
for another forte/sun one release before you can develop. The plug in 
supports a very broad range of tomcat versions. Eclipse has a linux 
version too ( in fact, I think it may even be written in java ) ! :-)




John Turner [EMAIL PROTECTED]
30/06/2003 13:55
Please respond to Tomcat Users List

 
To: Tomcat Users List [EMAIL PROTECTED]
cc: 
Subject:Re: multiuser setup: please help


Great, glad you got it working.

John

On Sat, 28 Jun 2003 23:18:11 -0230 (NDT), Neil Zanella 
[EMAIL PROTECTED] 
wrote:


 Thanks John! All I had to do was upgrade my Tomcat installation from
 the 4.0.1 version which comes with Java Sun One Studio (and is still
 being distributed at the Java site, huh!) to Tomcat 4.1.24, which at
 least is a stable release!

 I don't know why Java is still distributing j2sdk-1_4_1_02-s1studio_ce- 
 4u1-bin-linux.bin
 with Tomcat 4.0.1. They should make a new
 release with the updated Tomcat version
 (or not distribute Tomcat at all and
 encourage users to download the
 latest)!

 Neil



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





Possible workaround for invalid direct reference to login page

2003-06-27 Thread ben . jessel
Java Authentication with tomcat relies on realms. If you access a page 
protected by that realm you get directed to the login page.
However, it is possible to go directly to the login page ( this can happen 
when users bookmark the login page inadvertantly ).

This happens in two scenarios:

1) The user is already logged in.
2) The user is not logged in.

If you authenticate yourself once you have gone directly to the login 
page, you get a invalid direct reference error. Fair enough, the login 
page is trying to redirect to itself. Now, I tried to workaround this by 
checking if the session is null, and if it is, redirecting to some 
protected page, eg. protected/index.jsp. No luck. It seems that a session 
is implicitly created, and a new session id gets created.

So I've tried a cookie strategy:

%
if ( request.getCookies()==null ) {
response.sendRedirect(//jsp/protected/index.jsp);
}
if ( request.getRemoteUser()!=null )
{
response.sendRedirect(/x/jsp/protected/index.jsp);
}
%

i.e, we wont have a cookie if we've gone directly to the login page. But 
we will have if we've tried to access a protected page and then we've been 
forwarded to a login page, tomcat will give us a cookie.

Now if we're already logged in ( which we check with getRemoteUser() , 
then we just forward to user to an index page. 

This seems o.k. However my index page actually includes my login page! I'm 
planning to get around this with some logic that only includes the login 
page excerpt if we are not logged in..

Ben



Re: Hot deploy does not work?

2003-06-27 Thread ben . jessel
add reloadable=true in with the Context parameters




Jon Haugsand [EMAIL PROTECTED]
27/06/2003 15:43
Please respond to Tomcat Users List

 
To: [EMAIL PROTECTED]
cc: 
Subject:Hot deploy does not work?

Running tomcat 4.1 installed from RPM things look fine, but for some
reason or another I cannot get hot (re)deployment to work.  Copying a
war file into /var/tomcat4/webapps makes it jus lay there.

I mean this worked yesterday :-( but I cannot imagine what I have done
differently today except changing server.xml to use jdbc for
authentication.

I see that there is the following code in server.xml:

  Host name=localhost debug=0 appBase=webapps 
   unpackWARs=true autoDeploy=true

Is this what it should look like?  Other points to look into?

-- 
 Jon Haugsand, [EMAIL PROTECTED]
 http://www.norges-bank.no


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





Can't log in if PC clock different to server clock

2003-01-10 Thread Ben Jessel
I'm using JDBC realms, and I have found that I cannot log in if my PC clock is behind 
the server's clock. This may actually happen in production with many users. Does 
anyone know a workaround?

Thanks

Ben



bug with tomcat 4.1.18

2003-01-09 Thread Ben Jessel
I've noticed a bug when setting up tomcat 4.1.18 via the administration console.
It creates XML in server.xml which includes the parameter digest= ( if no digest is 
specified ). Tomcat actually tries to create a digester class with the zero length'd 
string. Delete this parameter out of you server.xml!

Oh yeah, and has anyone clicked on datasources and got a parse error, something like 
invalid parameter driverClassName ( even if none exists in server.xml, or in web.xml 
)?

Tomcat is a fantastic product, and I'm thankful that the development process has such 
a huge amount of impetus behind it, however the strife I've had with tomcat rpms /  
finding accurate documentation, and dealing with the bugs has been very frustrating...



ManagedBean is not found with Ajp13Connector

2003-01-03 Thread Ben Jessel
Hi, I've been suffering with trying to configure mod_jk + apache 1.3 + tomcat 1.4.18 
for a while. 
I've managed to get to a stage where I have a workers.properties, and an auto-created 
configuration for apache. However, I'm getting an error with this line of my server.xml

Connector className=org.apache.ajp.tomcat3.AjpConnector
port=8009 minProcessors=5 maxProcessors=75
acceptCount=10 debug=99/

ServerLifecycleListener: Creating MBean for Service 
StandardService[Tomcat-Standalone]
ServerLifecycleListener: Creating MBean for Connector 
org.apache.coyote.tomcat4.CoyoteConnector@19ce060
ServerLifecycleListener: Creating MBean for Connector 
org.apache.ajp.tomcat4.Ajp13Connector@13d28e3
java.lang.Exception: ManagedBean is not found with Ajp13Connector
at 
org.apache.catalina.mbeans.MBeanUtils.createMean(MBeanUtils.java:234)
..
...


Is tomcat4.1.18 not compatible with mod_jk?


Here's the server.xml

snip

!-- Example Server Configuration File --
!-- Note that component elements are nested corresponding to their
 parent-child relationships with each other --

!-- A Server is a singleton element that represents the entire JVM,
 which may contain one or more Service instances.  The Server
 listens for a shutdown command on the indicated port.

 Note:  A Server is not itself a Container, so you may not
 define subcomponents such as Valves or Loggers at this level.
 --

Server port=8005 shutdown=SHUTDOWN debug=99

 Listener className=org.apache.ajp.tomcat4.config.ApacheConfig
 modJk=/etc/httpd/modules/mod_jk.so
 jkDebug=info workersConfig=/usr/jakarta-tomcat-4.1.18/conf/workers.properties
 jkLog=/usr/jakarta-tomcat-4.1.18/logs/mod_jk.log /

  !-- Comment these entries out to disable JMX MBeans support --
  !-- You may also configure custom components (e.g. Valves/Realms) by 
   including your own mbean-descriptor file(s), and setting the 
   descriptors attribute to point to a ';' seperated list of paths
   (in the ClassLoader sense) of files to add to the default list.
   e.g. descriptors=/com/myfirm/mypackage/mbean-descriptor.xml
  --

  Listener className=org.apache.catalina.mbeans.ServerLifecycleListener
debug=99/
  Listener className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener
debug=99/

  !-- Global JNDI resources --
  GlobalNamingResources

!-- Test entry for demonstration purposes --
Environment name=simpleValue type=java.lang.Integer value=30/

!-- Editable user database that can also be used by
 UserDatabaseRealm to authenticate users --
Resource name=UserDatabase auth=Container
  type=org.apache.catalina.UserDatabase
   description=User database that can be updated and saved
/Resource
ResourceParams name=UserDatabase
  parameter
namefactory/name
valueorg.apache.catalina.users.MemoryUserDatabaseFactory/value
  /parameter
  parameter
namepathname/name
valueconf/tomcat-users.xml/value
  /parameter
/ResourceParams

  /GlobalNamingResources

  !-- A Service is a collection of one or more Connectors that share
   a single Container (and therefore the web applications visible
   within that Container).  Normally, that Container is an Engine,
   but this is not required.

   Note:  A Service is not itself a Container, so you may not
   define subcomponents such as Valves or Loggers at this level.
   --

  !-- Define the Tomcat Stand-Alone Service --
  Service name=Tomcat-Standalone

!-- A Connector represents an endpoint by which requests are received
 and responses are returned.  Each Connector passes requests on to the
 associated Container (normally an Engine) for processing.

 By default, a non-SSL HTTP/1.1 Connector is established on port 8080.
 You can also enable an SSL HTTP/1.1 Connector on port 8443 by
 following the instructions below and uncommenting the second Connector
 entry.  SSL support requires the following steps (see the SSL Config
 HOWTO in the Tomcat 4.0 documentation bundle for more detailed
 instructions):
 * Download and install JSSE 1.0.2 or later, and put the JAR files
   into $JAVA_HOME/jre/lib/ext.
 * Execute:
 %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA (Windows)
 $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA  (Unix)
   with a password value of changeit for both the certificate and
   the keystore itself.

 By default, DNS lookups are enabled when a web application calls
 request.getRemoteHost().  This can have an adverse impact on
 performance, so you can disable it by setting the
 enableLookups attribute to false.  When DNS lookups are disabled,
 request.getRemoteHost() will return the 

Re: ManagedBean is not found with Ajp13Connector

2003-01-03 Thread Ben Jessel
It's o.k I found the solution. Don't use AJP and JMX together. I guess they
put in JMX support and didn't want to support the old Ajp13Connector. Use
coyote instead. Having said that, that's as far as i've got...

- Original Message -
From: Ben Jessel [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Friday, January 03, 2003 11:43 AM
Subject: ManagedBean is not found with Ajp13Connector


Hi, I've been suffering with trying to configure mod_jk + apache 1.3 +
tomcat 1.4.18 for a while.
I've managed to get to a stage where I have a workers.properties, and an
auto-created configuration for apache. However, I'm getting an error with
this line of my server.xml

Connector className=org.apache.ajp.tomcat3.AjpConnector
port=8009 minProcessors=5 maxProcessors=75
acceptCount=10 debug=99/

ServerLifecycleListener: Creating MBean for Service
StandardService[Tomcat-Standalone]
ServerLifecycleListener: Creating MBean for Connector
org.apache.coyote.tomcat4.CoyoteConnector@19ce060
ServerLifecycleListener: Creating MBean for Connector
org.apache.ajp.tomcat4.Ajp13Connector@13d28e3
java.lang.Exception: ManagedBean is not found with Ajp13Connector
at
org.apache.catalina.mbeans.MBeanUtils.createMean(MBeanUtils.java:234)
..
...


Is tomcat4.1.18 not compatible with mod_jk?


Here's the server.xml

snip

!-- Example Server Configuration File --
!-- Note that component elements are nested corresponding to their
 parent-child relationships with each other --

!-- A Server is a singleton element that represents the entire JVM,
 which may contain one or more Service instances.  The Server
 listens for a shutdown command on the indicated port.

 Note:  A Server is not itself a Container, so you may not
 define subcomponents such as Valves or Loggers at this level.
 --

Server port=8005 shutdown=SHUTDOWN debug=99

 Listener className=org.apache.ajp.tomcat4.config.ApacheConfig
 modJk=/etc/httpd/modules/mod_jk.so
 jkDebug=info
workersConfig=/usr/jakarta-tomcat-4.1.18/conf/workers.properties
 jkLog=/usr/jakarta-tomcat-4.1.18/logs/mod_jk.log /

  !-- Comment these entries out to disable JMX MBeans support --
  !-- You may also configure custom components (e.g. Valves/Realms) by
   including your own mbean-descriptor file(s), and setting the
   descriptors attribute to point to a ';' seperated list of paths
   (in the ClassLoader sense) of files to add to the default list.
   e.g. descriptors=/com/myfirm/mypackage/mbean-descriptor.xml
  --

  Listener className=org.apache.catalina.mbeans.ServerLifecycleListener
debug=99/
  Listener
className=org.apache.catalina.mbeans.GlobalResourcesLifecycleListener
debug=99/

  !-- Global JNDI resources --
  GlobalNamingResources

!-- Test entry for demonstration purposes --
Environment name=simpleValue type=java.lang.Integer value=30/

!-- Editable user database that can also be used by
 UserDatabaseRealm to authenticate users --
Resource name=UserDatabase auth=Container
  type=org.apache.catalina.UserDatabase
   description=User database that can be updated and saved
/Resource
ResourceParams name=UserDatabase
  parameter
namefactory/name
valueorg.apache.catalina.users.MemoryUserDatabaseFactory/value
  /parameter
  parameter
namepathname/name
valueconf/tomcat-users.xml/value
  /parameter
/ResourceParams

  /GlobalNamingResources

  !-- A Service is a collection of one or more Connectors that share
   a single Container (and therefore the web applications visible
   within that Container).  Normally, that Container is an Engine,
   but this is not required.

   Note:  A Service is not itself a Container, so you may not
   define subcomponents such as Valves or Loggers at this level.
   --

  !-- Define the Tomcat Stand-Alone Service --
  Service name=Tomcat-Standalone

!-- A Connector represents an endpoint by which requests are received
 and responses are returned.  Each Connector passes requests on to
the
 associated Container (normally an Engine) for processing.

 By default, a non-SSL HTTP/1.1 Connector is established on port
8080.
 You can also enable an SSL HTTP/1.1 Connector on port 8443 by
 following the instructions below and uncommenting the second
Connector
 entry.  SSL support requires the following steps (see the SSL
Config
 HOWTO in the Tomcat 4.0 documentation bundle for more detailed
 instructions):
 * Download and install JSSE 1.0.2 or later, and put the JAR files
   into $JAVA_HOME/jre/lib/ext.
 * Execute:
 %JAVA_HOME%\bin\keytool -genkey -alias tomcat -keyalg RSA
(Windows)
 $JAVA_HOME/bin/keytool -genkey -alias tomcat -keyalg RSA
(Unix)
   with a password value

Realm not working now I've moved from Win2K to Linux

2003-01-02 Thread Ben Jessel
Hi,

I have a JDBC realm set up that interfaces with a mysql database in tomcat 4.0 on a 
windows 2000 server. This has been working fine - I place my pages under the security 
constraint, and I am forwarded to the login page o.k. Entering my details then puts me 
to the 'login correct' page, and all is good. Now I have now migrated to tomcat 4.0 on 
Mandrake 9, and I cannot log in. I have turned up debugging to full, and I can see 
that authorization is fine. I can see the sql and see the results being returned, 
however, I keep getting forwarded back to the login page. My configurations are very 
similar! Though, strangely enough, the RPM that I got from RPM finder has different 
ports configured to the win2k ones. I've replaced the server.xml with the one from the 
win2k distribution of Tomcat 4.0.

Thanks

Ben



Configuring realms in tomcat 3 vs tomcat 4

2002-12-19 Thread Ben Jessel
It seems to me that you can set up seperate realms for seperate web-applications in 
tomcat3 using the app-mywebapp.xml, but now that tomcat4's come out, you don't seem 
to be able to. How do you do it in tomcat4?



Re: Configuring realms in tomcat 3 vs tomcat 4

2002-12-19 Thread Ben Jessel
Aha...looks like you just put your realm code under the Context for your
application. Though I can't find a way of having multiple realms for a
single web-app..

-b
- Original Message -
From: Ben Jessel [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Thursday, December 19, 2002 10:58 AM
Subject: Configuring realms in tomcat 3 vs tomcat 4


It seems to me that you can set up seperate realms for seperate
web-applications in tomcat3 using the app-mywebapp.xml, but now that
tomcat4's come out, you don't seem to be able to. How do you do it in
tomcat4?



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




How to I post a bug / get in touch with the authors?

2002-12-18 Thread Ben Jessel
How would I go about posting a bug or getting in contact with the authors?

Thanks

Ben



Re: Multiple organisations in one realm with unique logins per organisations?

2002-12-17 Thread Ben Jessel
Sounds like you're going to need to create a custom realm in order do do
that extra select on the organisation.
Though, if you're going to have unique usernames throughout the system (
regardless of organisation ), then you could
work around this by having the organisations mapped to the user in the
user_role table. eg,

user password
userA  passA
userB  passB
userC  passC

user  role
userA   OrganisationA
userB   OrganisationA
userC   OrganisationC

Then you could restrict access to the different organisational areas of the
sites based on roles. Not the nicest solution, I think creating a custom
realm would be much more up your street. It's in the documentation.

Thanks

Ben

- Original Message -
From: Marc van de Geijn [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Tuesday, December 17, 2002 12:12 PM
Subject: Multiple organisations in one realm with unique logins per
organisations?


 Hi there,

 I'm developing an application which will support multiple organisations
 within one realm and one MySQL database.

 When users log into the application, I would like to make them enter their
 organisation name, their login and their password. Combining the login and
 the organisation name identifies the user unique in the realm/database.

 Is this possible with the standard authentication in Tomcat? Or are there
 other ways to do this?

 Thanks,
 Marc

 P.S. I hope I explained this problem correctly. Otherwise, just ask for
more
 information.


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




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




Re: Workaround for login page direct reference

2002-12-17 Thread Ben Jessel
Thanks Mike,

I guess, another workaround is that you could just invalidate their session
if they go to the login page
Now, I still don't see how all this is going help that direct reference to
login pageas it seems that I get this error if I go to login.jsp and
then enter in my details.

- Say the user goes to /login.jsp directly
- If we've protecteed that page Tomcat goes, no - that's a protected
resource, and forwards to /login.jsp
  Otherwise, tomcat just goes to the login page.
- You enter the user details, and then tomcat tries to forward to the page
you came from ( i.e  login.jsp ), but detects this is invalid ( presumably
by comparing against login-page in the web.xml,  and displays an error -
direct reference to login page

What I'd really, really, like, is some way of having an intermediate page
where I can check the requestURI to find out what page tomcat is going to
redirect me *after* login, so tomcat would give me
login.jsp?page_to_forward_to=blah.jsp... but alas, I don't think I can...

- Original Message -
From: Mike W-M [EMAIL PROTECTED]
To: Tomcat Users List [EMAIL PROTECTED]
Sent: Tuesday, December 17, 2002 11:28 AM
Subject: Re: Workaround for login page direct reference


 I'm going to have to sort this myself in the near future, but I don't
quite
 see how the fact that you can forward to the protected resource is going
to
 help?  Isn't Tomcat going to automatically redirect (not forward - the
 distinction is important since redirecting will result in the login page's
 URL showing up in the browser's address bar) to the login page you've
 configured?   Actually... since redirecting causes the browser to initiate
a
 new request (for your WEB-INF/login page in this case), won't you get a
 404-type error?

 Someone posted in a similar thread the other day that they intended to
check
 a couple of things in the login page:
 1. request.getRequestedSessionId() is *NULL* and
 2. There is *NO* cookie named JSESSIONID
 I think the theory was that these would both be true on the first occasion
 the login page was accessed, but that if the user was already
authenticated
 then the conditions wouldn't hold so the page should redirect to the index
 page.
 It's not nice to be relying on a cookie name (what if they change it
between
 versions, or if cookies are turned off (though I'm not sure the
 authentication works then anyway!)?) but I'm inclined to move in that
 direction when it's my turn

 Mike.



 - Original Message -
 From: Ben Jessel [EMAIL PROTECTED]
 To: Tomcat Users List [EMAIL PROTECTED]; Brett M.
 Bergquist [EMAIL PROTECTED]
 Sent: Tuesday, December 17, 2002 10:55 AM
 Subject: Re: Workaround for login page direct reference


 I'll give that a go.

 Thanks

 Ben
 - Original Message -
 From: Brett M. Bergquist [EMAIL PROTECTED]
 To: Tomcat Users List [EMAIL PROTECTED]; Ben Jessel
 [EMAIL PROTECTED]
 Sent: Monday, December 16, 2002 8:54 PM
 Subject: Re: Workaround for login page direct reference


  Ben, I'm not sure but I believe that I've seen mention that you can
 forward to a page that is not accessible to the outside.  That
  is, put the Login.jsp page within WEB-INF of your web app and it will
not
 be available to the outside world but you can forward to
  it from inside the web app.
 
  I don't know if this will work because I have not tried it but it might.
 
  Brett
 

 ..


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




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




Re: Workaround for login page direct reference

2002-12-17 Thread Ben Jessel
Thanks mech, that's very interesting, however, i simply just can't believe
that there are Tomcat instances out there in a live production environment
with configured realms that suffer from this problem. Surely there must be
something
- Original Message -
From: mech [EMAIL PROTECTED]
To: 'Tomcat Users List' [EMAIL PROTECTED]; 'Ben Jessel'
[EMAIL PROTECTED]
Sent: Tuesday, December 17, 2002 12:57 PM
Subject: RE: Workaround for login page direct reference


 Some more ideas...

 In my application I never have a direct link to the login.jsp.
 Try to link either to any file that will be accessed after login (e.g.
 content.jsp) or link only to the secure directory that you mapped and
 let the welcome-file redirect link to index.jsp or whatever.

 Doesn't solve the back button issue (check tomcat bug list), doesn't
 prohibit users to bookmark the login.jsp, but improves usability at
 least a bit by avoiding some opportunities to get errors.

 For your intermediate page thing I would suggest looking into using
 filters. Unfortunately nothing can prohibit the anyone from using the
 browser back button and try to relog again because in that back button
 case the login.jsp isn't even loaded again; so you can't even check for
 that error by any means.

 Michael

  -Original Message-
  From: Ben Jessel [mailto:[EMAIL PROTECTED]]
  Sent: Dienstag, 17. Dezember 2002 13:43
  To: Tomcat Users List
  Subject: Re: Workaround for login page direct reference
 
 
  Thanks Mike,
 
  I guess, another workaround is that you could just invalidate
  their session if they go to the login page Now, I still
  don't see how all this is going help that direct reference
  to login pageas it seems that I get this error if I go
  to login.jsp and then enter in my details.
 
  - Say the user goes to /login.jsp directly
  - If we've protecteed that page Tomcat goes, no - that's a
  protected resource, and forwards to /login.jsp
Otherwise, tomcat just goes to the login page.
  - You enter the user details, and then tomcat tries to
  forward to the page you came from ( i.e  login.jsp ), but
  detects this is invalid ( presumably by comparing against
  login-page in the web.xml,  and displays an error - direct
  reference to login page
 
  What I'd really, really, like, is some way of having an
  intermediate page where I can check the requestURI to find
  out what page tomcat is going to redirect me *after* login,
  so tomcat would give me
  login.jsp?page_to_forward_to=blah.jsp... but alas, I don't
  think I can...
 
  - Original Message -
  From: Mike W-M [EMAIL PROTECTED]
  To: Tomcat Users List [EMAIL PROTECTED]
  Sent: Tuesday, December 17, 2002 11:28 AM
  Subject: Re: Workaround for login page direct reference
 
 
   I'm going to have to sort this myself in the near future,
  but I don't
  quite
   see how the fact that you can forward to the protected resource is
   going
  to
   help?  Isn't Tomcat going to automatically redirect (not
  forward - the
   distinction is important since redirecting will result in the login
   page's URL showing up in the browser's address bar) to the
  login page you've
   configured?   Actually... since redirecting causes the
  browser to initiate
  a
   new request (for your WEB-INF/login page in this case),
  won't you get
   a 404-type error?
  
   Someone posted in a similar thread the other day that they
  intended to
  check
   a couple of things in the login page:
   1. request.getRequestedSessionId() is *NULL* and
   2. There is *NO* cookie named JSESSIONID
   I think the theory was that these would both be true on the first
   occasion the login page was accessed, but that if the user
  was already
  authenticated
   then the conditions wouldn't hold so the page should
  redirect to the
   index page. It's not nice to be relying on a cookie name
  (what if they
   change it
  between
   versions, or if cookies are turned off (though I'm not sure the
   authentication works then anyway!)?) but I'm inclined to
  move in that
   direction when it's my turn
  
   Mike.
  
  
  
   - Original Message -
   From: Ben Jessel [EMAIL PROTECTED]
   To: Tomcat Users List [EMAIL PROTECTED]; Brett M.
   Bergquist [EMAIL PROTECTED]
   Sent: Tuesday, December 17, 2002 10:55 AM
   Subject: Re: Workaround for login page direct reference
  
  
   I'll give that a go.
  
   Thanks
  
   Ben
   - Original Message -
   From: Brett M. Bergquist [EMAIL PROTECTED]
   To: Tomcat Users List [EMAIL PROTECTED];
  Ben Jessel
   [EMAIL PROTECTED]
   Sent: Monday, December 16, 2002 8:54 PM
   Subject: Re: Workaround for login page direct reference
  
  
Ben, I'm not sure but I believe that I've seen mention
  that you can
   forward to a page that is not accessible to the outside.  That
is, put the Login.jsp page within WEB-INF of your web app and it
will
  not
   be available to the outside world but you can forward to
it from

Workaround for login page direct reference

2002-12-16 Thread Ben Jessel
Hi,
I've got a realm set up on Tomcat. It works fine - whenever I go to a
protected page, I am forwarded to the login.jsp page.
However, if I go to the login.jsp page directly and fill in my details I get
Invalid direct reference to form login page. not surprising really as
tomcat would get itself into an endless cycle.

Now what are the strategies for hiding this page, so a hapless user who goes
directly to the login page and enters his details doesn't get this message.
I'd want to forward them onto the index page. Any ideas? Would I explicity
bar the request of the requesting of the login page using my web server?..I
doubt it, as I reckon tht the realm probably uses a sendRedirect(). I guess
that I could check the refering page...hmm dunno...any ideas?

Thanks

-b




Multiple realms in tomcat

2002-12-16 Thread Ben Jessel
Can you set up multiple JDBC realms in tomcat 4x or are you stuck with just the one?
Also, say that you had no control over configuring server.xml ( say, you had web-app 
space with an ISP ) is there any way you could configure a web-application wide realm  
without having to play around with other configuration files?

Thanks

Ben