DO NOT REPLY [Bug 29537] New: - User's identity and roles only for protected url
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29537. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29537 User's identity and roles only for protected url Summary: User's identity and roles only for protected url Product: Tomcat 5 Version: 5.0.25 Platform: Other OS/Version: Other Status: NEW Severity: Normal Priority: Other Component: Catalina AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] It seems Tomcat only sets the request user's identity (getUserPrincipal) and authorizations (isUserInRole) when the requested URL has been protected by security constraints. For example, if in my webapp i have two parts with path beginning with 'public' or 'protected', and i set a constraint on the second one, any request for the 'protected/...' URLs gives the correct user and roles, while all the 'public/...' always return a null user and false for role checkings. The same war deployed on Tomcat 4 and Weblogic 8 has the correct behaviour. Is this a change from the new servlet specification, or a bug ? Thanks for help. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 29537] - User's identity and roles only for protected url
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=29537. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=29537 User's identity and roles only for protected url [EMAIL PROTECTED] changed: What|Removed |Added Status|NEW |RESOLVED Resolution||DUPLICATE --- Additional Comments From [EMAIL PROTECTED] 2004-06-12 16:22 --- *** This bug has been marked as a duplicate of 12428 *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
DO NOT REPLY [Bug 12428] - request.getUserPrincipal(): Misinterpretation of specification?
DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT http://issues.apache.org/bugzilla/show_bug.cgi?id=12428. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND INSERTED IN THE BUG DATABASE. http://issues.apache.org/bugzilla/show_bug.cgi?id=12428 request.getUserPrincipal(): Misinterpretation of specification? [EMAIL PROTECTED] changed: What|Removed |Added CC||[EMAIL PROTECTED] --- Additional Comments From [EMAIL PROTECTED] 2004-06-12 16:22 --- *** Bug 29537 has been marked as a duplicate of this bug. *** - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
ForEach implementation lacks the final else clause, and some general suggestion
I am using tomcat 5.0.25 and it seems that forEach tag
is implemented to generate an if-else chain when it is given
an items parameter. The chain looks like this:
if (_jspx_temp16 instanceof Object[])
_jspx_temp17=toIterator((Object[])_jspx_temp16);
else if (_jspx_temp16 instanceof boolean[])
...
else if (_jspx_temp16 instanceof Enumeration)
_jspx_temp17=toIterator((Enumeration)_jspx_temp16);
else if (_jspx_temp16 instanceof Map)
_jspx_temp17=((Map)_jspx_temp16).entrySet().iterator();
while (_jspx_temp17.hasNext()){...}
This lacks the final catch-all else clause.
Because of this, if the items has a class object
that cannot be handled by the forEach implementation,
the temporary variable (_jspx_temp17 in this case)
remains null and attempting to invoke hasNext() on it
in the following while condition causes a generic
NPE.
For example, the following
tag expression causes this situation:
c:forEach var='x' items='${servletContext}'
li${x}/li
/c:forEach
When this happens, it is very hard to debug for non-Java
programmers which EL and JSTL is trying to address,
HTML authors without Java knowledge.
One has to read the translated Java file and understand
the relationship between the .jsp and .java file.
Perhaps the better way to handle this case is to have
the final else clause in which a JspTagException is thrown?
else
throw new JspTagException(
The \items\ attribute is given an object that cannot be iterated.);
I supposed this can be done relatively easily by inserting
another call to ctxt.generateJavaSource(else throw);
in
jakarta-tomcat-jasper/jasper2/src/share/org/apache/jasper/tagplugins/jstl/ForEach.java
More ideally, the exception message should include
the offending .jsp file name and the line number information
so that the JSP authoer can easily identify the offending
line, but I am not sure if it can be done easily under the
current implementation framework.
Regards,
--
KUROSAKA (Kuro) Teruhiko
San Francisco, California, USA
http://www.sonic.net/~kuro/
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
Re: Valide o seu email
A Panda Software Portual está a proteger-se contra as mensagens de email indesejadas o chamado Spam. Pedimos desculpa pelo incómodo mas o seu email não está ainda validado. Para que os seus emails sejam considerados como válidos, por favor, valide-se nesta página: http://www.startcontrol.com/GoodMail/Validate.asp?I=EMSYIFFMOBHIFHS Só necessita de se validar uma única vez. Todos os emails subsequentes serão considerados válidos. Obrigado. Panda Software Portugal
Re: Valide o seu email
A Panda Software Portual está a proteger-se contra as mensagens de email indesejadas o chamado Spam. Pedimos desculpa pelo incómodo mas o seu email não está ainda validado. Para que os seus emails sejam considerados como válidos, por favor, valide-se nesta página: http://www.startcontrol.com/GoodMail/Validate.asp?I=EMTPMFBACDLZFHJ Só necessita de se validar uma única vez. Todos os emails subsequentes serão considerados válidos. Obrigado. Panda Software Portugal
