You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tomcat.apache.org by "Mark R. Diggory" <md...@latte.harvard.edu> on 2002/02/19 00:01:20 UTC
Realms and User Sessions.
There are some objects I create inside my Custom Security Realm that I
want to make available in the Users session. Is there a way I can get
hold of the users session from within my custom realm class?
-Mark Diggory
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: Realms and User Sessions.
Posted by Mark Diggory <md...@latte.harvard.edu>.
I just wanted to finish up this thread...
Mark R. Diggory wrote:
>>
>>
>>>>
>>>> If you want to modify the state of the current request or session, you
>>>> should really be looking at subclassing one of the existing
>>>> Authenticator
>>>> classes, instead of trying to do that in the Realm.
>>>>
>>
>> The Authenticator is chosen based on which <login-method> you select.
>> One
>> of the four Authenticator valves will be selected automatically, based on
>> the mapping in the Authenticator.properties file in the
>> o.a.c.authenticators package.
>>
>
> All the Authenticators (Form, Basic,Digest...) appear to be 'final' in
> my catalina.jar archive (tomcat 4.0.1) making them not extendable.
>
> I could subclass AuthenticatorBase, but would that mean my Authenticator
> was unavailable in the o.a.c.startup.Authenticator.properties file ?
>
> Does this mean I'll have to configure and rebuilt tomcat to use my
> Authenticator?
>
> -Mark Diggory
>
>
>
> --
> To unsubscribe: <ma...@jakarta.apache.org>
> For additional commands: <ma...@jakarta.apache.org>
> Troubles with the list: <ma...@jakarta.apache.org>
>
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: Realms and User Sessions.
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
>
>
>>>
>>>If you want to modify the state of the current request or session, you
>>>should really be looking at subclassing one of the existing Authenticator
>>>classes, instead of trying to do that in the Realm.
>>>
>
>The Authenticator is chosen based on which <login-method> you select. One
>of the four Authenticator valves will be selected automatically, based on
>the mapping in the Authenticator.properties file in the
>o.a.c.authenticators package.
>
All the Authenticators (Form, Basic,Digest...) appear to be 'final' in
my catalina.jar archive (tomcat 4.0.1) making them not extendable.
I could subclass AuthenticatorBase, but would that mean my Authenticator
was unavailable in the o.a.c.startup.Authenticator.properties file ?
Does this mean I'll have to configure and rebuilt tomcat to use my
Authenticator?
-Mark Diggory
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: Realms and User Sessions.
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 18 Feb 2002, Mark R. Diggory wrote:
> Date: Mon, 18 Feb 2002 20:20:43 -0500
> From: Mark R. Diggory <md...@latte.harvard.edu>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: Tomcat Users List <to...@jakarta.apache.org>
> Subject: Re: Realms and User Sessions.
>
> >
> >
> >
> >I assume you are talking about Tomcat 4, right?
> >
> Yes.
>
> >
> >If so, there is no way for the Realm itself to reference the user's
> >session -- all a Realm knows how to do is answer the "is this user
> >authorized" and "does this user have the right role" type questions.
> >
> >If you want to modify the state of the current request or session, you
> >should really be looking at subclassing one of the existing Authenticator
> >classes, instead of trying to do that in the Realm. The Authenticator has
> >complete access to the current request, so you can get the session via:
> >
> > HttpSession session =
> > ((HttpRequest) request.getRequest()).getSession();
> >
> >Don't forget to put the classes for the objects you might create into
> >common/lib so that they are visible to both Catalina and your webapp.
> >
> >
> >Craig
> >
> Well, I learn something new every day....
>
> So, let me see if I have this correct.
>
> 1.) I define a <valve> pointing to my custom authentication class in my
> server.xml (in my webapps context).
>
> <Context path="/VDC" docBase="VDC" debug="0" reloadable="true">
> <Valve className="edu.harvard.hmdc.authenticator.VdcAuthenticator"
> debug="0"/>
> </Context>
>
> 2.) Dump my files into tomcat/common to support that valve.
> 3.) Then define any security constraints required by my webapp in its
> web.xml file.
>
> <security-constraint>
> <display-name>Administration Pages</display-name>
> <web-resource-collection>
> <web-resource-name>Protected Area</web-resource-name>
> <!-- Define the context-relative URL(s) to be protected -->
> <url-pattern>/Administration/*</url-pattern>
> </web-resource-collection>
> <auth-constraint>
> <!-- Anyone with one of the listed roles may access this
> area -->
> <role-name>administrators</role-name>
> <role-name>curators</role-name>
> </auth-constraint>
> </security-constraint>
> <!-- Default login configuration uses form-based authentication -->
> <login-config>
> <auth-method>FORM</auth-method>
> <realm-name>Example Form-Based Authentication Area</realm-name>
> <form-login-config>
> <form-login-page>/Authority/login.jsp</form-login-page>
> <form-error-page>/Authority/error.jsp</form-error-page>
> </form-login-config>
> </login-config>
>
>
> After this any security constraints should activate the
> Valve/Authenticator and not a Realm for authentication? How does Tomcat
> know which Authenticator to use?
>
The Authenticator is chosen based on which <login-method> you select. One
of the four Authenticator valves will be selected automatically, based on
the mapping in the Authenticator.properties file in the
o.a.c.authenticators package.
> Just make sure, does this still in any way require the use of a Realm class?
There still needs to be a Realm that actually looks up users in a
database, but the choice of Realm is orthagonal to the choice of
Authenticator -- any combination of the two is valid. As with a standard
Tomcat install, the Realm can be either directly associated with a
Context, or inherited from the owning Host or Engine.
>
> -Mark
>
Craig
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: Realms and User Sessions.
Posted by "Mark R. Diggory" <md...@latte.harvard.edu>.
>
>
>
>I assume you are talking about Tomcat 4, right?
>
Yes.
>
>If so, there is no way for the Realm itself to reference the user's
>session -- all a Realm knows how to do is answer the "is this user
>authorized" and "does this user have the right role" type questions.
>
>If you want to modify the state of the current request or session, you
>should really be looking at subclassing one of the existing Authenticator
>classes, instead of trying to do that in the Realm. The Authenticator has
>complete access to the current request, so you can get the session via:
>
> HttpSession session =
> ((HttpRequest) request.getRequest()).getSession();
>
>Don't forget to put the classes for the objects you might create into
>common/lib so that they are visible to both Catalina and your webapp.
>
>
>Craig
>
Well, I learn something new every day....
So, let me see if I have this correct.
1.) I define a <valve> pointing to my custom authentication class in my
server.xml (in my webapps context).
<Context path="/VDC" docBase="VDC" debug="0" reloadable="true">
<Valve className="edu.harvard.hmdc.authenticator.VdcAuthenticator"
debug="0"/>
</Context>
2.) Dump my files into tomcat/common to support that valve.
3.) Then define any security constraints required by my webapp in its
web.xml file.
<security-constraint>
<display-name>Administration Pages</display-name>
<web-resource-collection>
<web-resource-name>Protected Area</web-resource-name>
<!-- Define the context-relative URL(s) to be protected -->
<url-pattern>/Administration/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<!-- Anyone with one of the listed roles may access this
area -->
<role-name>administrators</role-name>
<role-name>curators</role-name>
</auth-constraint>
</security-constraint>
<!-- Default login configuration uses form-based authentication -->
<login-config>
<auth-method>FORM</auth-method>
<realm-name>Example Form-Based Authentication Area</realm-name>
<form-login-config>
<form-login-page>/Authority/login.jsp</form-login-page>
<form-error-page>/Authority/error.jsp</form-error-page>
</form-login-config>
</login-config>
After this any security constraints should activate the
Valve/Authenticator and not a Realm for authentication? How does Tomcat
know which Authenticator to use?
Just make sure, does this still in any way require the use of a Realm class?
-Mark
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Re: Realms and User Sessions.
Posted by "Craig R. McClanahan" <cr...@apache.org>.
On Mon, 18 Feb 2002, Mark R. Diggory wrote:
> Date: Mon, 18 Feb 2002 18:01:20 -0500
> From: Mark R. Diggory <md...@latte.harvard.edu>
> Reply-To: Tomcat Users List <to...@jakarta.apache.org>
> To: tomcat-user@jakarta.apache.org
> Subject: Realms and User Sessions.
>
> There are some objects I create inside my Custom Security Realm that I
> want to make available in the Users session. Is there a way I can get
> hold of the users session from within my custom realm class?
>
I assume you are talking about Tomcat 4, right?
If so, there is no way for the Realm itself to reference the user's
session -- all a Realm knows how to do is answer the "is this user
authorized" and "does this user have the right role" type questions.
If you want to modify the state of the current request or session, you
should really be looking at subclassing one of the existing Authenticator
classes, instead of trying to do that in the Realm. The Authenticator has
complete access to the current request, so you can get the session via:
HttpSession session =
((HttpRequest) request.getRequest()).getSession();
Don't forget to put the classes for the objects you might create into
common/lib so that they are visible to both Catalina and your webapp.
> -Mark Diggory
>
Craig
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>
Tomcat 4_0_2 JSP Does Not Work in Default
Posted by Shannon Brown <re...@shannonbrown.net>.
Tomcat 4.0.2
Sun JDK 1.4.0 Final
Apache 1.3
RedHat Linux 7.2
What I Did:
I had a working installation of Tomcat 4.0.1 this morning. I downloaded and
installed the new 4.0.2 RPMs. The RPMs would not run out-of-the-box. I had
to comment out the Tomcat-Apache Section of server.xml to get the Tomcat
Service to start.
Tomcat is running (ps -A). I see the default index.html page for the
examples section. I can run the servlet examples without any problems.
However, when I try to run the JSP examples, I get an error message.
Checking the logs, any JSP invocation is throwing a 500 error.
Not sure why and really do not know where to begin since everything else
(finally) seems to be running.
||||||||||||||||||||||||||||||||||||||||||||
Shannon Brown
Internet Technologies Architect
Business Technologies Advisor
www.shannonbrown.net
info@shannonbrown.net
717.665.5656
||||||||||||||||||||||||||||||||||||||||||||
--
To unsubscribe: <ma...@jakarta.apache.org>
For additional commands: <ma...@jakarta.apache.org>
Troubles with the list: <ma...@jakarta.apache.org>