Re: does tomcat automatically revert to url rewriting...
Craig R. McClanahan wrote: On Fri, 22 Nov 2002, jfc wrote: Date: Fri, 22 Nov 2002 11:11:28 + From: jfc <[EMAIL PROTECTED]> Reply-To: Tomcat Users List <[EMAIL PROTECTED]> To: Tomcat Users List <[EMAIL PROTECTED]> Subject: Re: does tomcat automatically revert to url rewriting... Craig R. McClanahan wrote: On Fri, 22 Nov 2002, jfc wrote: Will tomcat *automatically* go through the effort of rewriting the URL if the session *cannot* be persisted via the cookie?(i.e. do I need to watch for clients that don't support cookies or can I rest assured that tomcat knows whether or not a request has a cookie and so when cookies are not there then it encodes each request for me?) Tomcat does indeed know if a session id cookie was received (and you can find out as well, by calling request.isSessionIdFromCookie()). If that is the case, response.encodeURL() and response.encodeRedirectURL() will return the argument unmodified. OK. So that means I don't need to be concerned with when I should use the call(s) and when I should not - I should always wrap my links and redirects in these calls. (assuming my application uses sessions) Yes. One subtlety should be pointed out, though -- consider what happens on the very first response for a new session. At that point in time, Tomcat has no idea whether the client supports cookies or not. Therefore, it sends the session id both ways (rewriting and a cookie). On subsequent requests, if the cookie has been returned, Tomcat will stop rewriting. ok. We also need to remember that Tomcat does *not* scan the output your servlet or JSP page creates, and modifies the hyperlinks. If you do not call encodeURL() or encodeRedirectURL() yourself when creating the output, URL rewriting will never occur (and your app will require the client to support cookies if it uses sessions). ok. I've got that. Now, I am using struts 1.1b2 so if I have tags (and the others tags which render urls) embedded in my jsps, should I wrap these tags manually or does struts do the wrapping? If struts automatically does it for me (as the docs suggest) then the above answer for me (using struts) is not relevent. Correct? Yes. The Struts tags that generate URLs all do the encodeURL() calls for you, so you don't have to think about it. Craig jfc Craig -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> Thanks Craig! jfc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
HttpSessionContext deprecation question
Hi, I see that this class is now deprecated with the 2.1 servlet api. Can someone please explain to me briefly why this is? I know its down to security but a little more of the theory behind the decision would be interesting. I am trying to provide the functionality to admin users of our site and have found that its easy to achieve(storing user objects in the app scope as users enter the site or login) but before I go ahead and make it available, I thought I'd better check. thanks jfc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: does tomcat automatically revert to url rewriting...
Craig R. McClanahan wrote: On Fri, 22 Nov 2002, jfc wrote: Will tomcat *automatically* go through the effort of rewriting the URL if the session *cannot* be persisted via the cookie?(i.e. do I need to watch for clients that don't support cookies or can I rest assured that tomcat knows whether or not a request has a cookie and so when cookies are not there then it encodes each request for me?) Tomcat does indeed know if a session id cookie was received (and you can find out as well, by calling request.isSessionIdFromCookie()). If that is the case, response.encodeURL() and response.encodeRedirectURL() will return the argument unmodified. OK. So that means I don't need to be concerned with when I should use the call(s) and when I should not - I should always wrap my links and redirects in these calls. (assuming my application uses sessions) One subtlety should be pointed out, though -- consider what happens on the very first response for a new session. At that point in time, Tomcat has no idea whether the client supports cookies or not. Therefore, it sends the session id both ways (rewriting and a cookie). On subsequent requests, if the cookie has been returned, Tomcat will stop rewriting. ok. We also need to remember that Tomcat does *not* scan the output your servlet or JSP page creates, and modifies the hyperlinks. If you do not call encodeURL() or encodeRedirectURL() yourself when creating the output, URL rewriting will never occur (and your app will require the client to support cookies if it uses sessions). ok. I've got that. Now, I am using struts 1.1b2 so if I have tags (and the others tags which render urls) embedded in my jsps, should I wrap these tags manually or does struts do the wrapping? If struts automatically does it for me (as the docs suggest) then the above answer for me (using struts) is not relevent. Correct? Craig jfc -- 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: does tomcat automatically revert to url rewriting...
Tim Funk wrote: To use URL rewriting all your URLS must first wrapped in response.encodeRedirectURL() So does this mean that tomcat does not automatically do the encoding in the absence of cookies? That being said: response.encodeRedirectURL() will rewrite the URL to add jsessionid if there was no incoming session cookie. AFAIK - tomcat will not go through the effort of rewriting the URL if the session can be persisted via the cookie. Will tomcat *automatically* go through the effort of rewriting the URL if the session *cannot* be persisted via the cookie?(i.e. do I need to watch for clients that don't support cookies or can I rest assured that tomcat knows whether or not a request has a cookie and so when cookies are not there then it encodes each request for me?) jfc wrote: Hi I'm using struts1.1b2, tomcat 406 and jboss3 1. Does tomcat automatically revert to url rewriting when the browser doesn't support cookies? 2. If not, do I have to do something to enforce url rewriting? I want to do whatever it takes to track sessions in my application. jfc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> jfc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
incomplete form-based authentication
Hi, tomcat 406, struts1.1b2 I'm using form-based authentication. I would like to know what happens when the following happens: I request a secured resource but instead of submitting a 'j_security_check' html form with my username and password, I instead ignore it and continue browsing other links on the page. Does the container hold onto the original request and if so what is its policy for doing so - i.e. how and how long for? Thanks jfc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
does tomcat automatically revert to url rewriting...
Hi I'm using struts1.1b2, tomcat 406 and jboss3 1. Does tomcat automatically revert to url rewriting when the browser doesn't support cookies? 2. If not, do I have to do something to enforce url rewriting? I want to do whatever it takes to track sessions in my application. jfc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: a 'one-click' j_securty_check question
David Cassidy wrote: > i think that unless Im completly missing your point your missing the > Realm's point. (Or I am) > > When you log in using the realm it takes from the database all your > associated roles. ie > if you have admin, editor and journo roles but you only need 'editor' > role for the area you want > to go into TC gets all the roles and associates it with your principle. > > > Have a look at RealmBase > > http://jakarta.apache.org/tomcat/tomcat-4.1-doc/catalina/docs/api/index.html > > > You can then get the principle for that user then check if that user > is in a > given role. You can then build your page based on those roles. ( which is > what I think you are trying to do ) > > Hope this helps > > D > > > jfc wrote: > >> Hi, >> >> I would like to structure my application so that the user can choose >> to login instead of being enexpectedly prompted to be logged in. >> >> It seems declarative form-based security comes with the philosophy >> that your URL has to explicilty request a resource which is secured >> under the role you wish to log in under in order for the container to >> know you belong to that particular role(i.e. >> request.getRemoteUser()). So you have to know before hand who you'd >> like to be logged in as. >> >> I could force the user to choose from a list of valid roles before he >> gets propmted by the j_security_check login form but I'm trying not >> to have force the user to identify himself to the container twice in >> order to be thoroughly recognized by the container. >> >> My question: >> >> Is the following possible under the latest spec and tomcat's >> implementation (using j2ee, declarative form-based authentication >> ): >> >> 1.user issues a request to manually log in with the custom html >> login form containing the users username and password; >> 2.server extracts role-leaf from this user's registration >> information from a persistent store i.e. the application holds roles >> in a hierarchy; >> 3.server does a redirect to a welcome page secured in web.xml >> under that role-leaf role value; >> 4.the configured login page has the j_security_check form >> prepopulated with username and password; >> 5.the configured login page also has an 'onload' javascript >> directive which automatically submits j_security_check on loading of >> the body. >> >> I haven't tried this yet but does anyone have any experience of >> something like this working? >> >> If so it would mean that an application would not have to show links >> whose appropriateness would only become apparent once that link had >> been followed(clicked) and the user had possibly failed at his >> attempted login. >> >> Sorry if this is not clear enough. >> >> jfc >> >> (the container needs to first know what role you want to log in under >> in order for it to successfully authenticate you under that role. It >> can't determine for itself which role you registered under and >> attempt to authenticate you under that role instead) >> >> >> -- >> 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]> > > Thanks for that I'll have a read. jfc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: a 'one-click' j_securty_check question
Eddie Bush wrote: > Suggestion: Search the archive. This is a very frequently asked > question. > > What you want to do is the same as everyone else using FORM-based CMA. > The fact is that it doesn't work on a "let" basis; rather a "make" > basis. One hint I will give you: the container is going to load all > of a user's roles when they login. They don't login as a given role > (to my understanding anyhow), but simply login -- all associated roles > are loaded on successful authentication. > > Regards, > > Eddie > > jfc wrote: > >> Hi, >> >> I would like to structure my application so that the user can choose >> to login instead of being enexpectedly prompted to be logged in. >> >> It seems declarative form-based security comes with the philosophy >> that your URL has to explicilty request a resource which is secured >> under the role you wish to log in under in order for the container to >> know you belong to that particular role(i.e. >> request.getRemoteUser()). So you have to know before hand who you'd >> like to be logged in as. >> >> I could force the user to choose from a list of valid roles before he >> gets propmted by the j_security_check login form but I'm trying not >> to have force the user to identify himself to the container twice in >> order to be thoroughly recognized by the container. >> >> My question: >> >> Is the following possible under the latest spec and tomcat's >> implementation (using j2ee, declarative form-based authentication >> ): >> >> 1.user issues a request to manually log in with the custom html >> login form containing the users username and password; >> 2.server extracts role-leaf from this user's registration >> information from a persistent store i.e. the application holds roles >> in a hierarchy; >> 3.server does a redirect to a welcome page secured in web.xml >> under that role-leaf role value; >> 4.the configured login page has the j_security_check form >> prepopulated with username and password; >> 5.the configured login page also has an 'onload' javascript >> directive which automatically submits j_security_check on loading of >> the body. >> >> I haven't tried this yet but does anyone have any experience of >> something like this working? >> >> If so it would mean that an application would not have to show links >> whose appropriateness would only become apparent once that link had >> been followed(clicked) and the user had possibly failed at his >> attempted login. >> >> Sorry if this is not clear enough. >> >> jfc >> >> (the container needs to first know what role you want to log in under >> in order for it to successfully authenticate you under that role. It >> can't determine for itself which role you registered under and >> attempt to authenticate you under that role instead) >> >> >> -- >> 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]> > > Thanks Eddie! -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
a 'one-click' j_securty_check question
Hi, I would like to structure my application so that the user can choose to login instead of being enexpectedly prompted to be logged in. It seems declarative form-based security comes with the philosophy that your URL has to explicilty request a resource which is secured under the role you wish to log in under in order for the container to know you belong to that particular role(i.e. request.getRemoteUser()). So you have to know before hand who you'd like to be logged in as. I could force the user to choose from a list of valid roles before he gets propmted by the j_security_check login form but I'm trying not to have force the user to identify himself to the container twice in order to be thoroughly recognized by the container. My question: Is the following possible under the latest spec and tomcat's implementation (using j2ee, declarative form-based authentication ): 1.user issues a request to manually log in with the custom html login form containing the users username and password; 2.server extracts role-leaf from this user's registration information from a persistent store i.e. the application holds roles in a hierarchy; 3.server does a redirect to a welcome page secured in web.xml under that role-leaf role value; 4.the configured login page has the j_security_check form prepopulated with username and password; 5.the configured login page also has an 'onload' javascript directive which automatically submits j_security_check on loading of the body. I haven't tried this yet but does anyone have any experience of something like this working? If so it would mean that an application would not have to show links whose appropriateness would only become apparent once that link had been followed(clicked) and the user had possibly failed at his attempted login. Sorry if this is not clear enough. jfc (the container needs to first know what role you want to log in under in order for it to successfully authenticate you under that role. It can't determine for itself which role you registered under and attempt to authenticate you under that role instead) -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: altering the request URI in a filter
Martin Cooper wrote: >OK, I'm confused now. Your original question was about how you could alter >the request URI in a filter. Now, however, you seem to be asking about how >you can alter the request URI in a Struts Action class or in your own >version of the Struts RequestProcessor. What are you really trying to do? > >If you want to modify what the request object looks like to everyone, using >a filter, my previous answer applies: Write a request wrapper which returns >a different value than the original from methods such as getRequestURI(). > >If you want to do something inside of Struts, you'll have to make do with >the RequestDispatcher, as someone else suggested. > >-- >Martin Cooper > > >>-Original Message- >>From: jfc [mailto:[EMAIL PROTECTED]] >>Sent: Tuesday, September 03, 2002 6:26 AM >>To: Tomcat Users List >>Subject: Re: altering the request URI in a filter >> >> >>Martin Cooper wrote: >> >>>>-Original Message- >>>>From: jfc [mailto:[EMAIL PROTECTED]] >>>>Sent: Monday, September 02, 2002 1:51 AM >>>>To: Tomcat Users List >>>>Subject: Re: altering the request URI in a filter >>>> >>>> >>>[snip] >>> >>>>Hi, >>>> >>>>Thanks for the reply. How can I actually set the new value/s on the >>>>request? I don't see any setter methods or any fields which >>>>can be used >>>>to hold the new value. >>>> >>>>The only setters I can see are setAttribute and setRequest. >>>> >>>Since you're the one implementing the wrapper class, you can >>> >>choose to add >> >>>whatever methods you see fit. >>> >>>-- >>>Martin Cooper >>> >>> >>>>jfc >>>> >>>> >>>> >>>>-- >>>>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]> >> >>> >>Hi Martin, >> >>If I create a request wrapper, I can add whatever state and >>accessor or >>other methods which may be useful to some other process that >>knows that >>they are there. What I am really asking is this: >> >>Because I am using struts, I have a ActionServlet and a request >>processor which based on the request's stored URI, locates a mapping >>which is defined in struts-config.xml and this mapping directs to a >>handler (my action class). I want to be able to change the >>URI (the one >>which the framework uses to locate the mapping) so that a different >>mapping will be selected. >> >>So I'm not talking about adding specific behaviour or state to the >>request - I want to access the existing state and modify it >>and have the >>framework go about it's usual business of doing the delegating to my >>action etc (based on the updated state). >> >>It is possible to override the ActionServlet and/or the request >>processor in struts which may or may not be neccessary - depending on >>what can be achieved from a filter. >> >>So I want to know where I could alter the request URI with >>this change >>being visible to what ever processes the request to select the struts >>mapping. >> >> >>cheers >>jfc >> >> >> >> >>-- >>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]> > > I see now what you were saying. This would work just as well. Thanks. jfc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: altering the request URI in a filter
Martin Cooper wrote: >OK, I'm confused now. Your original question was about how you could alter >the request URI in a filter. Now, however, you seem to be asking about how >you can alter the request URI in a Struts Action class or in your own >version of the Struts RequestProcessor. What are you really trying to do? > Alter the request URI. > > >If you want to modify what the request object looks like to everyone, using >a filter, my previous answer applies: Write a request wrapper which returns >a different value than the original from methods such as getRequestURI(). > I only wanted to make sure the change I did (to the request URI) would be visible by whatever struts class does the mapping selection. I didn't know then that using a requestDispatcher would do the trick so I was thinking if it was not possible(to do this using filters) then I might be able to achieve the alteration to the request URI by overriding the appropriate method in the struts request processor. > >If you want to do something inside of Struts, you'll have to make do with >the RequestDispatcher, as someone else suggested. > This I have now done. Thanks for your input ;-) > >-- >Martin Cooper > Any ideas as to how best to slip the string back into the outgoing html's links? What is the best way to do this? Thanks again. jfc > >>-Original Message- >>From: jfc [mailto:[EMAIL PROTECTED]] >>Sent: Tuesday, September 03, 2002 6:26 AM >>To: Tomcat Users List >>Subject: Re: altering the request URI in a filter >> >> >>Martin Cooper wrote: >> >>>>-Original Message- >>>>From: jfc [mailto:[EMAIL PROTECTED]] >>>>Sent: Monday, September 02, 2002 1:51 AM >>>>To: Tomcat Users List >>>>Subject: Re: altering the request URI in a filter >>>> >>>> >>>[snip] >>> >>>>Hi, >>>> >>>>Thanks for the reply. How can I actually set the new value/s on the >>>>request? I don't see any setter methods or any fields which >>>>can be used >>>>to hold the new value. >>>> >>>>The only setters I can see are setAttribute and setRequest. >>>> >>>Since you're the one implementing the wrapper class, you can >>> >>choose to add >> >>>whatever methods you see fit. >>> >>>-- >>>Martin Cooper >>> >>> >>>>jfc >>>> >>>> >>>> >>>>-- >>>>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]> >> >>> >>Hi Martin, >> >>If I create a request wrapper, I can add whatever state and >>accessor or >>other methods which may be useful to some other process that >>knows that >>they are there. What I am really asking is this: >> >>Because I am using struts, I have a ActionServlet and a request >>processor which based on the request's stored URI, locates a mapping >>which is defined in struts-config.xml and this mapping directs to a >>handler (my action class). I want to be able to change the >>URI (the one >>which the framework uses to locate the mapping) so that a different >>mapping will be selected. >> >>So I'm not talking about adding specific behaviour or state to the >>request - I want to access the existing state and modify it >>and have the >>framework go about it's usual business of doing the delegating to my >>action etc (based on the updated state). >> >>It is possible to override the ActionServlet and/or the request >>processor in struts which may or may not be neccessary - depending on >>what can be achieved from a filter. >> >>So I want to know where I could alter the request URI with >>this change >>being visible to what ever processes the request to select the struts >>mapping. >> >> >>cheers >>jfc >> >> >> >> >>-- >>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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: altering the request URI in a filter
Cox, Charlie wrote:
>>>I'm getting
>>>
>>>java.lang.IllegalStateException: Cannot forward after response has
>>>been committed
>>>
>>>... etc
>>>
>>>At the end of my filter's doFilter method I am doing the following:
>>>
>>> if(stripped){
>>> RequestDispatcher rd =
>>>request.getRequestDispatcher(requestURI);
>>> if(rd != null){
>>> rd.forward(request, response);
>>> }
>>> }
>>> chain.doFilter(request, response);
>>>
>>>Do I need to invoke the chainFilter?
>>>
>>Sorry that should be Do I need to invoke the chain.doFilter method?
>>
>
>no, putreturn; after your forward().
>
>>>jfc
>>>
>>>
>>>--
>>>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]>
>>
>
>--
>To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
>For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
Charlie,
Your request dispatcher suggestion worked without the chain.doFilter.
Thanks for that!
jfc
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: altering the request URI in a filter
jfc wrote:
> Cox, Charlie wrote:
>
>> would RequestDispather.forward() work for you? you can use this from
>> within
>> your filter and it will not reinvoke the authentication.
>>
>> Charlie
>>
>>> -Original Message-
>>> From: jfc [mailto:[EMAIL PROTECTED]]
>>> Sent: Tuesday, September 03, 2002 9:26 AM
>>> To: Tomcat Users List
>>> Subject: Re: altering the request URI in a filter
>>>
>>>
>>> Martin Cooper wrote:
>>>
>>>>> -Original Message-
>>>>> From: jfc [mailto:[EMAIL PROTECTED]]
>>>>> Sent: Monday, September 02, 2002 1:51 AM
>>>>> To: Tomcat Users List
>>>>> Subject: Re: altering the request URI in a filter
>>>>>
>>>>>
>>>> [snip]
>>>>
>>>>> Hi,
>>>>>
>>>>> Thanks for the reply. How can I actually set the new value/s on
>>>>> the request? I don't see any setter methods or any fields which
>>>>> can be used to hold the new value.
>>>>>
>>>>> The only setters I can see are setAttribute and setRequest.
>>>>>
>>>> Since you're the one implementing the wrapper class, you can
>>>
>>> choose to add
>>>
>>>> whatever methods you see fit.
>>>>
>>>> --
>>>> Martin Cooper
>>>>
>>>>
>>>>> jfc
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> 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]>
>>>
>>>>
>>> Hi Martin,
>>>
>>> If I create a request wrapper, I can add whatever state and accessor
>>> or other methods which may be useful to some other process that
>>> knows that they are there. What I am really asking is this:
>>>
>>> Because I am using struts, I have a ActionServlet and a request
>>> processor which based on the request's stored URI, locates a mapping
>>> which is defined in struts-config.xml and this mapping directs to a
>>> handler (my action class). I want to be able to change the URI (the
>>> one which the framework uses to locate the mapping) so that a
>>> different mapping will be selected.
>>>
>>> So I'm not talking about adding specific behaviour or state to the
>>> request - I want to access the existing state and modify it and have
>>> the framework go about it's usual business of doing the delegating
>>> to my action etc (based on the updated state).
>>>
>>> It is possible to override the ActionServlet and/or the request
>>> processor in struts which may or may not be neccessary - depending
>>> on what can be achieved from a filter.
>>>
>>> So I want to know where I could alter the request URI with this
>>> change being visible to what ever processes the request to select
>>> the struts mapping.
>>>
>>>
>>> cheers
>>> jfc
>>>
>>>
>>>
>>>
>>> --
>>> 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]>
>>
>>
> I'm getting
>
> java.lang.IllegalStateException: Cannot forward after response has
> been committed
>
> ... etc
>
> At the end of my filter's doFilter method I am doing the following:
>
>if(stripped){
>RequestDispatcher rd =
> request.getRequestDispatcher(requestURI);
>if(rd != null){
>rd.forward(request, response);
>}
>}
> chain.doFilter(request, response);
>
> Do I need to invoke the chainFilter?
Sorry that should be Do I need to invoke the chain.doFilter method?
>
> jfc
>
>
> --
> 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: altering the request URI in a filter
Cox, Charlie wrote:
>would RequestDispather.forward() work for you? you can use this from within
>your filter and it will not reinvoke the authentication.
>
>Charlie
>
>>-Original Message-
>>From: jfc [mailto:[EMAIL PROTECTED]]
>>Sent: Tuesday, September 03, 2002 9:26 AM
>>To: Tomcat Users List
>>Subject: Re: altering the request URI in a filter
>>
>>
>>Martin Cooper wrote:
>>
>>>>-Original Message-
>>>>From: jfc [mailto:[EMAIL PROTECTED]]
>>>>Sent: Monday, September 02, 2002 1:51 AM
>>>>To: Tomcat Users List
>>>>Subject: Re: altering the request URI in a filter
>>>>
>>>>
>>>[snip]
>>>
>>>>Hi,
>>>>
>>>>Thanks for the reply. How can I actually set the new value/s on the
>>>>request? I don't see any setter methods or any fields which
>>>>can be used
>>>>to hold the new value.
>>>>
>>>>The only setters I can see are setAttribute and setRequest.
>>>>
>>>Since you're the one implementing the wrapper class, you can
>>>
>>choose to add
>>
>>>whatever methods you see fit.
>>>
>>>--
>>>Martin Cooper
>>>
>>>
>>>>jfc
>>>>
>>>>
>>>>
>>>>--
>>>>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]>
>>
>>>
>>Hi Martin,
>>
>>If I create a request wrapper, I can add whatever state and
>>accessor or
>>other methods which may be useful to some other process that
>>knows that
>>they are there. What I am really asking is this:
>>
>>Because I am using struts, I have a ActionServlet and a request
>>processor which based on the request's stored URI, locates a mapping
>>which is defined in struts-config.xml and this mapping directs to a
>>handler (my action class). I want to be able to change the
>>URI (the one
>>which the framework uses to locate the mapping) so that a different
>>mapping will be selected.
>>
>>So I'm not talking about adding specific behaviour or state to the
>>request - I want to access the existing state and modify it
>>and have the
>>framework go about it's usual business of doing the delegating to my
>>action etc (based on the updated state).
>>
>>It is possible to override the ActionServlet and/or the request
>>processor in struts which may or may not be neccessary - depending on
>>what can be achieved from a filter.
>>
>>So I want to know where I could alter the request URI with
>>this change
>>being visible to what ever processes the request to select the struts
>>mapping.
>>
>>
>>cheers
>>jfc
>>
>>
>>
>>
>>--
>>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]>
>
>
I'm getting
java.lang.IllegalStateException: Cannot forward after response has been committed
... etc
At the end of my filter's doFilter method I am doing the following:
if(stripped){
RequestDispatcher rd = request.getRequestDispatcher(requestURI);
if(rd != null){
rd.forward(request, response);
}
}
chain.doFilter(request, response);
Do I need to invoke the chainFilter?
jfc
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: altering the request URI in a filter
Martin Cooper wrote: > >>-Original Message- >>From: jfc [mailto:[EMAIL PROTECTED]] >>Sent: Monday, September 02, 2002 1:51 AM >>To: Tomcat Users List >>Subject: Re: altering the request URI in a filter >> >> > >[snip] > >>Hi, >> >>Thanks for the reply. How can I actually set the new value/s on the >>request? I don't see any setter methods or any fields which >>can be used >>to hold the new value. >> >>The only setters I can see are setAttribute and setRequest. >> > >Since you're the one implementing the wrapper class, you can choose to add >whatever methods you see fit. > >-- >Martin Cooper > > >>jfc >> >> >> >>-- >>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]> > > Hi Martin, If I create a request wrapper, I can add whatever state and accessor or other methods which may be useful to some other process that knows that they are there. What I am really asking is this: Because I am using struts, I have a ActionServlet and a request processor which based on the request's stored URI, locates a mapping which is defined in struts-config.xml and this mapping directs to a handler (my action class). I want to be able to change the URI (the one which the framework uses to locate the mapping) so that a different mapping will be selected. So I'm not talking about adding specific behaviour or state to the request - I want to access the existing state and modify it and have the framework go about it's usual business of doing the delegating to my action etc (based on the updated state). It is possible to override the ActionServlet and/or the request processor in struts which may or may not be neccessary - depending on what can be achieved from a filter. So I want to know where I could alter the request URI with this change being visible to what ever processes the request to select the struts mapping. cheers jfc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: altering the request URI in a filter
Bill Barker wrote: >"jfc" <[EMAIL PROTECTED]> wrote in message >[EMAIL PROTECTED]">news:[EMAIL PROTECTED]... > >>Hi, >> >>Tomcat 404, jdk1.3: >> >>Is it possible to alter the request's URI after authentication but >>before the request is delegated to a Struts action mapping? >> > >The beauty of Filters is that anything is possible :-). The Filter (at >least under Tomcat) will only be invoked after authentication, but before >the Struts servlet. > >>I would like to be able to strip a string from the request URI which is >>there solely for the purposes of enforcing the web container to obtain >>authentication and authorization info. (if the web container's auth >>cache has been turned off). >> > >You would need to wrap the Request with one that over-rides (at least) >getRequestURI, and getServletPath, and in some cases, getPathInfo (although, >since Struts uses extension mappings, the last one shouldn't apply in your >case). > >>Cheers >>jfc >> > > > > > >-- >To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> >For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> > > Hi, Thanks for the reply. How can I actually set the new value/s on the request? I don't see any setter methods or any fields which can be used to hold the new value. The only setters I can see are setAttribute and setRequest. jfc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
altering the request URI in a filter
Hi, Tomcat 404, jdk1.3: Is it possible to alter the request's URI after authentication but before the request is delegated to a Struts action mapping? I would like to be able to strip a string from the request URI which is there solely for the purposes of enforcing the web container to obtain authentication and authorization info. (if the web container's auth cache has been turned off). Cheers jfc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: does authorization occurr for each request?
Craig R. McClanahan wrote: > >On Wed, 28 Aug 2002, jfc wrote: > >>Date: Wed, 28 Aug 2002 21:03:10 +0000 >>From: jfc <[EMAIL PROTECTED]> >>Reply-To: Tomcat Users List <[EMAIL PROTECTED]> >>To: Tomcat Users List <[EMAIL PROTECTED]> >>Subject: Re: does authorization occurr for each request? >> >>Hi, >> >>What kind of caching does the following tag disable? >> >> > debug="3" cache="false"/> >> > >If you are using sessions, Tomcat normally caches the looked-up Principal >object in the session so that it doesn't need to be looked up on every >request. Setting the "cache" property to false disables this. > >>According to Scott Stark from jboss, caching is turned off within the >>jboss/tomcat bundle with the above tag. And this is the default as there >>are conflicts with the propagation to the ejb layer). How does this >>affect the web container's ability to recognize a previously >>authenticated request on a subsequent request to a non-secured resource >>(within the same session). It appears as though tomcat won't hold the >>info neccessary to authorize the request. >> > >You'll have to ask the JBoss folks how they deal with this issue, since >they are modifying Tomcat's default behavior. > >>Where does tomcat cache this info when caching is on >> > >In private variables associated with the internal object that implements >HttpSession. > >>and how can I >>manually cache the info >> > >You can't access this stuff from a webapp; the only thing you can do is >set or not set the "cache" property. > > - and, again, what is the info (username and > >>password and roles or just roles?). >> > >The standard Authenticator caches the Principal object returned by the >Realm. In the case of Tomcat's standard Realm implementations, this is an >org.apache.catalina.realm.GenericPrincipal that stores the username and >all the roles. I haven't got a clue what JBoss's Realm might return. > >>I'm trying to establish whether I need to secure every single requested >>resource in order to get the web container to 'remember' the session's >>authentication or whether by doing some kind of caching myself, I can >>effectively replace this particular caching of tomcat's (which is turned >>off by default in the jboss/tomcat bundles) >> > >You really need to be asking the JBoss folks these questions, since their >integration changes the behavior of some of Tomcat's standard components, >and replaces others. But I don't really understand why you care about the >internal implementation details in the first place -- as long as the >combined Tomcat+JBoss server acts in a spec-compliant manner with regards >to security, isn't that enough? > >>thanks >> >>jfc >> > >Craig > > >>Craig R. McClanahan wrote: >> >>>On Wed, 28 Aug 2002, jfc wrote: >>> >>>>Date: Wed, 28 Aug 2002 14:11:51 + >>>>From: jfc <[EMAIL PROTECTED]> >>>>Reply-To: Tomcat Users List <[EMAIL PROTECTED]> >>>>To: tomcat-user <[EMAIL PROTECTED]> >>>>Subject: does authorization occurr for each request? >>>> >>>>Hi, >>>> >>>>A question re declarative security and form-based authentication and >>>>subsequent request authorization: >>>> >>>>Can anyone confirm whether or not authorization(i.e. role checking) is >>>>repeated for each request(to a secured resource) after a user has been >>>>authenticated? >>>> >>>Yes, it is. The URL from each request is matched against the security >>>constraints you have defined, and the specified role restrictions are >>>enforced on every request. >>> >>>>There would be times when a subsequent request comes in to a resource >>>>secured under a role which is higher or lower within the applications >>>>user hierarchy and I need to know what behaviour tomcat implements. >>>> >>>Tomcat doesn't know anything about "higher" or "lower" roles. It only >>>asks whether a user has one of the roles listed in the security >>>constraint. >>> >>>>Tomcat will surely have a list of valid roles for a particular >>>>authenticated user right? This would make sense as a check can be >>>>performed as and when required to determine whether or not the user has >>>>been
Re: does authorization occurr for each request?
Hi, What kind of caching does the following tag disable? According to Scott Stark from jboss, caching is turned off within the jboss/tomcat bundle with the above tag. And this is the default as there are conflicts with the propagation to the ejb layer). How does this affect the web container's ability to recognize a previously authenticated request on a subsequent request to a non-secured resource (within the same session). It appears as though tomcat won't hold the info neccessary to authorize the request. Where does tomcat cache this info when caching is on and how can I manually cache the info - and, again, what is the info (username and password and roles or just roles?). I'm trying to establish whether I need to secure every single requested resource in order to get the web container to 'remember' the session's authentication or whether by doing some kind of caching myself, I can effectively replace this particular caching of tomcat's (which is turned off by default in the jboss/tomcat bundles) thanks jfc Craig R. McClanahan wrote: > >On Wed, 28 Aug 2002, jfc wrote: > >>Date: Wed, 28 Aug 2002 14:11:51 + >>From: jfc <[EMAIL PROTECTED]> >>Reply-To: Tomcat Users List <[EMAIL PROTECTED]> >>To: tomcat-user <[EMAIL PROTECTED]> >>Subject: does authorization occurr for each request? >> >>Hi, >> >>A question re declarative security and form-based authentication and >>subsequent request authorization: >> >>Can anyone confirm whether or not authorization(i.e. role checking) is >>repeated for each request(to a secured resource) after a user has been >>authenticated? >> > >Yes, it is. The URL from each request is matched against the security >constraints you have defined, and the specified role restrictions are >enforced on every request. > >>There would be times when a subsequent request comes in to a resource >>secured under a role which is higher or lower within the applications >>user hierarchy and I need to know what behaviour tomcat implements. >> > >Tomcat doesn't know anything about "higher" or "lower" roles. It only >asks whether a user has one of the roles listed in the security >constraint. > >>Tomcat will surely have a list of valid roles for a particular >>authenticated user right? This would make sense as a check can be >>performed as and when required to determine whether or not the user has >>been assigned the required role. >> > >In the default Realm implementations, the list of roles assigned to a user >is cached in the Principal object that resulted from authentication, so >the role checking is an in-memory lookup in a HashMap. However, it's >perfectly reasonable to implement a Realm that goes to a database (or some >other external source of information) every time -- especially useful in >scenarios where the set of roles might be changing (such as a role that >says "can use this URL from 8am to 5pm on weekdays"). > >>jfc >> > >Craig > > >-- >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]>
does authorization occurr for each request?
Hi, A question re declarative security and form-based authentication and subsequent request authorization: Can anyone confirm whether or not authorization(i.e. role checking) is repeated for each request(to a secured resource) after a user has been authenticated? There would be times when a subsequent request comes in to a resource secured under a role which is higher or lower within the applications user hierarchy and I need to know what behaviour tomcat implements. Tomcat will surely have a list of valid roles for a particular authenticated user right? This would make sense as a check can be performed as and when required to determine whether or not the user has been assigned the required role. jfc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
sending login details using SSL
Hi, Should it be common practice to send login details (username + password) via SSL? I'll be using form-based authentication and was wondering about how to beef up the security of transmitting username and password over http. I understand there is a transport-guarantee tag for use in web.xml. How would this generally be achieved ie how would one specify that all logins - regardless of which resource was requested, should be marked as CONFIDENTIAL? Thanks jfc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: tomcat4 + declarative security
Andreas Mohrig wrote: >I'm using Tomcat/4.0.4 with Apache 1.3.26 (mod_jk) on SuSE Linux 7.3 >(without JBoss or struts). > >Do you really get responses with the same session-id, but different results >of getRemoteUser()? > >Andreas Mohrig >-Original Message- >From: jfc [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, August 21, 2002 7:15 PM >To: Tomcat Users List >Subject: Re: tomcat4 + declarative security > > >Andreas Mohrig wrote: > >>The answers are "yes" and "yes". You can determine the user's >>"logged-in-ness" with a call to "request.getRemoteUser()", which should >>return "null" if he is not and his name (login) otherwise. This should >>always be the case, regardless of the currently requested resource having a >>security-constraint or nor, but of course a login will only be demanded if >>it has such a constraint. >> >>If you experience different behaviour, I will surely be interested to learn >>about it. >> >>Andreas Mohrig >>-Original Message- >>From: jfc [mailto:[EMAIL PROTECTED]] >>Sent: Wednesday, August 21, 2002 1:26 PM >>To: [EMAIL PROTECTED] >>Subject: tomcat4 + declarative security >> >> >>Hi, >> >>I have two questions regarding declarative security ( I use >>JBoss2.4.x+Tomcat4.0 + struts1.1, on suse linux7.2 - ): >> >>1.Is tomcat 4 supposed to be able to distinguish previously >>authenticated users from unauthenticated users? >> >> I assumed the answer to this question is yes because otherwise the >>user would have to undergo the entire authentication process repeatedly >>for each request that he submits within a single session. >> >>2.Is tomcat 4 supposed to be able to do the above (i.e. remember a >>user's logged-in-ness) regardless of whether his current request was to >>a secured resource? (again assume requests are within the same session). >> >>cheers >>jfc >> >> >>-- >>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]> > >> >Right, well I have a situation where point 2 is not working. If I roll >my versions back to bundle jb243+tc40, I get the predicted behaviour of >which you speak. > >What version/s are you using? > >jfc > > > >-- >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]> > > The answer is yes. Can I email you my tomcat 'demo-auth-prob' war file?(which utilizes users.properties and roles.properties - so it shows the problem without referring to jboss). If you need the src, I can email it too. jfc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: tomcat4 + declarative security
Andreas Mohrig wrote: >The answers are "yes" and "yes". You can determine the user's >"logged-in-ness" with a call to "request.getRemoteUser()", which should >return "null" if he is not and his name (login) otherwise. This should >always be the case, regardless of the currently requested resource having a >security-constraint or nor, but of course a login will only be demanded if >it has such a constraint. > >If you experience different behaviour, I will surely be interested to learn >about it. > >Andreas Mohrig >-Original Message- >From: jfc [mailto:[EMAIL PROTECTED]] >Sent: Wednesday, August 21, 2002 1:26 PM >To: [EMAIL PROTECTED] >Subject: tomcat4 + declarative security > > >Hi, > >I have two questions regarding declarative security ( I use >JBoss2.4.x+Tomcat4.0 + struts1.1, on suse linux7.2 - ): > >1.Is tomcat 4 supposed to be able to distinguish previously >authenticated users from unauthenticated users? > >I assumed the answer to this question is yes because otherwise the >user would have to undergo the entire authentication process repeatedly >for each request that he submits within a single session. > >2.Is tomcat 4 supposed to be able to do the above (i.e. remember a >user's logged-in-ness) regardless of whether his current request was to >a secured resource? (again assume requests are within the same session). > >cheers >jfc > > >-- >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]> > > Right, well I have a situation where point 2 is not working. If I roll my versions back to bundle jb243+tc40, I get the predicted behaviour of which you speak. What version/s are you using? jfc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
tomcat4 + declarative security
Hi, I have two questions regarding declarative security ( I use JBoss2.4.x+Tomcat4.0 + struts1.1, on suse linux7.2 - ): 1.Is tomcat 4 supposed to be able to distinguish previously authenticated users from unauthenticated users? I assumed the answer to this question is yes because otherwise the user would have to undergo the entire authentication process repeatedly for each request that he submits within a single session. 2.Is tomcat 4 supposed to be able to do the above (i.e. remember a user's logged-in-ness) regardless of whether his current request was to a secured resource? (again assume requests are within the same session). cheers jfc -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
Re: ODBC-JDBC ** with JSP ** : 'No suitable driver'
Hi ~ I'm back, with an answer to my problem ! But first of all, thank you a lot to all who helped me. Nice to see such a quick knowledge-network. The problem ? Wasn't in JDBC classes, nor in lib paths. I even removed all copied 'classes12.zip' (or 'classes12.jar' or anything) from everywhere except from the Oracle native directory, and it works. Sowhat ? Well it was about ODBC (just smile, ok) The database was only configured as local-user ODBC-available, instead of system (=>services => tomcat) ODBC-available. As soon as I add the test database in ODBC configuration panel's *system* tab, the 'getConnection(String, String, String)' method call suceeded. I thought it could though be an hint for anyone else.. ^-^ Jean-François
Re: ODBC-JDBC ** with JSP ** : 'No suitable driver'
Hello ~
Actually I unzipped the classes12.zip file in 2 directories !
1° %TOMCAT_HOME%\lib
2° {my_webbApp}\WEB-INF\classes
Moreover, the classes12.zip file still remains in the %TOMCAT_HOME%/lib
directory... ^-^
I nevertheless feel like it's still a CLASSPATH or dir problem...
Coz it works fine with a "java {my_MainClassName}" DOS command !
But thanx for your answers !
Jean-François
>Hi,
If you unzipped the file into the WEB-INF/lib directory, then
you did it in the wrong place. They should go in the WEB-INF/classes
directory. I've been using that approach successfully here for a while
now.
Brendan
: Ok, I'll try that.
: Nevertheless, I already tried to put the developped classtree of
: classes12.zip (oracle.jdbc) in the lib directory (unzipped file), and
: it didn't work properly either. I may guess that renaming the .zip
in .jar
: would have the same (non-)effect, wouldn't it ?
:
: Jean-François
:
:
--
Brendan McKennaEmail: [EMAIL PROTECTED]
Development StrategistPhone: +353-61-338177
Taringold Ltd.Fax: +353-61-338065
Re: ODBC-JDBC ** with JSP ** : 'No suitable driver'
Ok, I'll try that. Nevertheless, I already tried to put the developped classtree of classes12.zip (oracle.jdbc) in the lib directory (unzipped file), and it didn't work properly either. I may guess that renaming the .zip in .jar would have the same (non-)effect, wouldn't it ? Jean-François >Try to rename the classes12.zip into classes12.jar. >Tomcat only adds the jar files existing in the lib directory to its >classpath. >Benoît > Thanx, Tom. But I already did that, and also the nls* file matching the > release. > It doesn't work better.. > > Jean-François > > >put the classes12.zip in the $TOMCAT_HOME/lib directory. > > > >regards, tom > > > >> -Ursprüngliche Nachricht- > > > > Von: JFC [mailto:[EMAIL PROTECTED]] > > Gesendet: Mittwoch, 2. Mai 2001 16:33 > > An: [EMAIL PROTECTED] > > Betreff: ODBC-JDBC ** with JSP ** : 'No suitable driver' > > > > > > > > Hi ~ > > > > Sorry if this issue has recently come, I'm new to this mailing list. > > Please be lenient... ^-^ > > > > My problem is quite wide-spread, as I can see on different FAQ, but none > > of them solution it. Maybe you can help. > > > > I'm trying to run a JSP application under Jakarta on PC Win 2000 Server, > > IIS 5, Jakarta as NT service. > > And I'm getting the error "No suitable driver" on the getConnection(...) > > method call, when trying to connect to an Oracle 8i instance. > > > > I mention that a standalone Java program running with the MS JVM calling > > the same method with the same arguments on the same Oracle instance. > > > > Thank you for your help ~ > > > > JF
Re: Why USe Apache
Hello ~ Because it's written in Jakarta's specification : Tomcat serves static pages worse than Apache or IIS. Maybe there are other reasons... Jean-François >Excuse me if this question is obvious. If Tomcat can be run in a standalone mode, why should it be used in conjunction with apache? Thanks Dallas Skinner
Re: ODBC-JDBC ** with JSP ** : 'No suitable driver'
Thanx, Tom. But I already did that, and also the nls* file matching the release. It doesn't work better.. Jean-François >put the classes12.zip in the $TOMCAT_HOME/lib directory. >regards, tom >> -Ursprüngliche Nachricht- > Von: JFC [mailto:[EMAIL PROTECTED]] > Gesendet: Mittwoch, 2. Mai 2001 16:33 > An: [EMAIL PROTECTED] > Betreff: ODBC-JDBC ** with JSP ** : 'No suitable driver' > > > > Hi ~ > > Sorry if this issue has recently come, I'm new to this mailing list. > Please be lenient... ^-^ > > My problem is quite wide-spread, as I can see on different FAQ, but none > of them solution it. Maybe you can help. > > I'm trying to run a JSP application under Jakarta on PC Win 2000 Server, > IIS 5, Jakarta as NT service. > And I'm getting the error "No suitable driver" on the getConnection(...) > method call, when trying to connect to an Oracle 8i instance. > > I mention that a standalone Java program running with the MS JVM calling > the same method with the same arguments on the same Oracle instance. > > Thank you for your help ~ > > JF > >
ODBC-JDBC ** with JSP ** : 'No suitable driver' : followsup !
Sorry I forgot the end of my last sentence in the post : "I mention that a standalone Java program running with the MS JVM calling the same method with the same arguments on the same Oracle instance"... succeeds in hooking the connection with the running instance. Regards, Jean-françois
ODBC-JDBC ** with JSP ** : 'No suitable driver'
Hi ~ Sorry if this issue has recently come, I'm new to this mailing list. Please be lenient... ^-^ My problem is quite wide-spread, as I can see on different FAQ, but none of them solution it. Maybe you can help. I'm trying to run a JSP application under Jakarta on PC Win 2000 Server, IIS 5, Jakarta as NT service. And I'm getting the error "No suitable driver" on the getConnection(...) method call, when trying to connect to an Oracle 8i instance. I mention that a standalone Java program running with the MS JVM calling the same method with the same arguments on the same Oracle instance. Thank you for your help ~ JF
