You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@beehive.apache.org by "Abdessattar Sassi (JIRA)" <be...@incubator.apache.org> on 2005/05/10 12:55:08 UTC
[jira] Created: (BEEHIVE-635) Tomcat PageflowValve does not check for security-constraints defined in web.xml
Tomcat PageflowValve does not check for security-constraints defined in web.xml
-------------------------------------------------------------------------------
Key: BEEHIVE-635
URL: http://issues.apache.org/jira/browse/BEEHIVE-635
Project: Beehive
Type: Bug
Components: NetUI
Versions: V1Alpha, V1Beta, V1
Environment: Using beehive latest from SVN and Tomcat 5.5.7
Reporter: Abdessattar Sassi
The Tomcat implementation of the Pipeline for a Context is such that only one Valve which is also an Authenticator valve is added to the Pipeline. The standard Tomcat Authenticator valves (e.g. BasicAuthenticator) check for and honor all the security constraints specified in the webapp web.xml descriptor.
The PageflowValve implementation part of tomcat-server under netui is an Authenticaor valve as it extends BasicAuthenticator, which means that it is mutually exclusive with the regular Tomcat authenticator valves (only one can be in the pipeline). It does not however keep the features that were part of the AuthenticatorBase and the BasicAuthentiocator invoke() method implementation. Such issue results for example in the user-data-constraint elements being completely ignored, and therefore pages who are supposed to be served only with SSL are always served without SSL.
Following is an example of the code from the regular Tomcat authenticators that is missing from beehive adapter (please note that the code is from Tomcat 5.5.7 with which by the way beehive does not compile, but should give you a good idea of the missing features...):
// Enforce any user data constraint for this security constraint
if (log.isDebugEnabled()) {
log.debug(" Calling hasUserDataPermission()");
}
Realm realm = this.context.getRealm();
// Is this request URI subject to a security constraint?
SecurityConstraint [] constraints
= realm.findSecurityConstraints(request, this.context);
if (!realm.hasUserDataPermission(request, response,
constraints)) {
if (log.isDebugEnabled()) {
log.debug(" Failed hasUserDataPermission() test");
}
/*
* ASSERT: Authenticator already set the appropriate
* HTTP status code, so we do not have to do anything special
*/
return;
}
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (BEEHIVE-635) Tomcat PageflowValve does not check for security-constraints defined in web.xml
Posted by "Eddie O'Neil (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-635?page=all ]
Eddie O'Neil updated BEEHIVE-635:
---------------------------------
Fix Version: TBD
Same thing in 635 as with the fix version in 634:
http://issues.apache.org/jira/browse/BEEHIVE-635
This is definitely something we should support post 1.0; moving to fix in TBD.
Abdessattar, looks like you're halfway to a patch here. :)
> Tomcat PageflowValve does not check for security-constraints defined in web.xml
> -------------------------------------------------------------------------------
>
> Key: BEEHIVE-635
> URL: http://issues.apache.org/jira/browse/BEEHIVE-635
> Project: Beehive
> Type: Bug
> Components: NetUI
> Versions: V1Alpha, V1Beta, V1
> Environment: Using beehive latest from SVN and Tomcat 5.5.7
> Reporter: Abdessattar Sassi
> Fix For: TBD
>
> The Tomcat implementation of the Pipeline for a Context is such that only one Valve which is also an Authenticator valve is added to the Pipeline. The standard Tomcat Authenticator valves (e.g. BasicAuthenticator) check for and honor all the security constraints specified in the webapp web.xml descriptor.
> The PageflowValve implementation part of tomcat-server under netui is an Authenticaor valve as it extends BasicAuthenticator, which means that it is mutually exclusive with the regular Tomcat authenticator valves (only one can be in the pipeline). It does not however keep the features that were part of the AuthenticatorBase and the BasicAuthentiocator invoke() method implementation. Such issue results for example in the user-data-constraint elements being completely ignored, and therefore pages who are supposed to be served only with SSL are always served without SSL.
> Following is an example of the code from the regular Tomcat authenticators that is missing from beehive adapter (please note that the code is from Tomcat 5.5.7 with which by the way beehive does not compile, but should give you a good idea of the missing features...):
> // Enforce any user data constraint for this security constraint
> if (log.isDebugEnabled()) {
> log.debug(" Calling hasUserDataPermission()");
> }
> Realm realm = this.context.getRealm();
> // Is this request URI subject to a security constraint?
> SecurityConstraint [] constraints
> = realm.findSecurityConstraints(request, this.context);
> if (!realm.hasUserDataPermission(request, response,
> constraints)) {
> if (log.isDebugEnabled()) {
> log.debug(" Failed hasUserDataPermission() test");
> }
> /*
> * ASSERT: Authenticator already set the appropriate
> * HTTP status code, so we do not have to do anything special
> */
> return;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (BEEHIVE-635) Tomcat PageflowValve does not check for security-constraints defined in web.xml
Posted by "Rich Feit (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-635?page=all ]
Rich Feit updated BEEHIVE-635:
------------------------------
Fix Version: V1
(was: TBD)
Description:
The Tomcat implementation of the Pipeline for a Context is such that only one Valve which is also an Authenticator valve is added to the Pipeline. The standard Tomcat Authenticator valves (e.g. BasicAuthenticator) check for and honor all the security constraints specified in the webapp web.xml descriptor.
The PageflowValve implementation part of tomcat-server under netui is an Authenticaor valve as it extends BasicAuthenticator, which means that it is mutually exclusive with the regular Tomcat authenticator valves (only one can be in the pipeline). It does not however keep the features that were part of the AuthenticatorBase and the BasicAuthentiocator invoke() method implementation. Such issue results for example in the user-data-constraint elements being completely ignored, and therefore pages who are supposed to be served only with SSL are always served without SSL.
Following is an example of the code from the regular Tomcat authenticators that is missing from beehive adapter (please note that the code is from Tomcat 5.5.7 with which by the way beehive does not compile, but should give you a good idea of the missing features...):
// Enforce any user data constraint for this security constraint
if (log.isDebugEnabled()) {
log.debug(" Calling hasUserDataPermission()");
}
Realm realm = this.context.getRealm();
// Is this request URI subject to a security constraint?
SecurityConstraint [] constraints
= realm.findSecurityConstraints(request, this.context);
if (!realm.hasUserDataPermission(request, response,
constraints)) {
if (log.isDebugEnabled()) {
log.debug(" Failed hasUserDataPermission() test");
}
/*
* ASSERT: Authenticator already set the appropriate
* HTTP status code, so we do not have to do anything special
*/
return;
}
was:
The Tomcat implementation of the Pipeline for a Context is such that only one Valve which is also an Authenticator valve is added to the Pipeline. The standard Tomcat Authenticator valves (e.g. BasicAuthenticator) check for and honor all the security constraints specified in the webapp web.xml descriptor.
The PageflowValve implementation part of tomcat-server under netui is an Authenticaor valve as it extends BasicAuthenticator, which means that it is mutually exclusive with the regular Tomcat authenticator valves (only one can be in the pipeline). It does not however keep the features that were part of the AuthenticatorBase and the BasicAuthentiocator invoke() method implementation. Such issue results for example in the user-data-constraint elements being completely ignored, and therefore pages who are supposed to be served only with SSL are always served without SSL.
Following is an example of the code from the regular Tomcat authenticators that is missing from beehive adapter (please note that the code is from Tomcat 5.5.7 with which by the way beehive does not compile, but should give you a good idea of the missing features...):
// Enforce any user data constraint for this security constraint
if (log.isDebugEnabled()) {
log.debug(" Calling hasUserDataPermission()");
}
Realm realm = this.context.getRealm();
// Is this request URI subject to a security constraint?
SecurityConstraint [] constraints
= realm.findSecurityConstraints(request, this.context);
if (!realm.hasUserDataPermission(request, response,
constraints)) {
if (log.isDebugEnabled()) {
log.debug(" Failed hasUserDataPermission() test");
}
/*
* ASSERT: Authenticator already set the appropriate
* HTTP status code, so we do not have to do anything special
*/
return;
}
> Tomcat PageflowValve does not check for security-constraints defined in web.xml
> -------------------------------------------------------------------------------
>
> Key: BEEHIVE-635
> URL: http://issues.apache.org/jira/browse/BEEHIVE-635
> Project: Beehive
> Type: Bug
> Components: NetUI
> Versions: V1Alpha, v1m1, V1Beta
> Environment: Using beehive latest from SVN and Tomcat 5.5.7
> Reporter: Abdessattar Sassi
> Assignee: Rich Feit
> Fix For: V1
> Attachments: patch.txt
>
> The Tomcat implementation of the Pipeline for a Context is such that only one Valve which is also an Authenticator valve is added to the Pipeline. The standard Tomcat Authenticator valves (e.g. BasicAuthenticator) check for and honor all the security constraints specified in the webapp web.xml descriptor.
> The PageflowValve implementation part of tomcat-server under netui is an Authenticaor valve as it extends BasicAuthenticator, which means that it is mutually exclusive with the regular Tomcat authenticator valves (only one can be in the pipeline). It does not however keep the features that were part of the AuthenticatorBase and the BasicAuthentiocator invoke() method implementation. Such issue results for example in the user-data-constraint elements being completely ignored, and therefore pages who are supposed to be served only with SSL are always served without SSL.
> Following is an example of the code from the regular Tomcat authenticators that is missing from beehive adapter (please note that the code is from Tomcat 5.5.7 with which by the way beehive does not compile, but should give you a good idea of the missing features...):
> // Enforce any user data constraint for this security constraint
> if (log.isDebugEnabled()) {
> log.debug(" Calling hasUserDataPermission()");
> }
> Realm realm = this.context.getRealm();
> // Is this request URI subject to a security constraint?
> SecurityConstraint [] constraints
> = realm.findSecurityConstraints(request, this.context);
> if (!realm.hasUserDataPermission(request, response,
> constraints)) {
> if (log.isDebugEnabled()) {
> log.debug(" Failed hasUserDataPermission() test");
> }
> /*
> * ASSERT: Authenticator already set the appropriate
> * HTTP status code, so we do not have to do anything special
> */
> return;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Assigned: (BEEHIVE-635) Tomcat PageflowValve does not check for security-constraints defined in web.xml
Posted by "Rich Feit (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-635?page=all ]
Rich Feit reassigned BEEHIVE-635:
---------------------------------
Assign To: Rich Feit
> Tomcat PageflowValve does not check for security-constraints defined in web.xml
> -------------------------------------------------------------------------------
>
> Key: BEEHIVE-635
> URL: http://issues.apache.org/jira/browse/BEEHIVE-635
> Project: Beehive
> Type: Bug
> Components: NetUI
> Versions: V1Alpha, v1m1, V1Beta
> Environment: Using beehive latest from SVN and Tomcat 5.5.7
> Reporter: Abdessattar Sassi
> Assignee: Rich Feit
> Fix For: V1
> Attachments: patch.txt
>
> The Tomcat implementation of the Pipeline for a Context is such that only one Valve which is also an Authenticator valve is added to the Pipeline. The standard Tomcat Authenticator valves (e.g. BasicAuthenticator) check for and honor all the security constraints specified in the webapp web.xml descriptor.
> The PageflowValve implementation part of tomcat-server under netui is an Authenticaor valve as it extends BasicAuthenticator, which means that it is mutually exclusive with the regular Tomcat authenticator valves (only one can be in the pipeline). It does not however keep the features that were part of the AuthenticatorBase and the BasicAuthentiocator invoke() method implementation. Such issue results for example in the user-data-constraint elements being completely ignored, and therefore pages who are supposed to be served only with SSL are always served without SSL.
> Following is an example of the code from the regular Tomcat authenticators that is missing from beehive adapter (please note that the code is from Tomcat 5.5.7 with which by the way beehive does not compile, but should give you a good idea of the missing features...):
> // Enforce any user data constraint for this security constraint
> if (log.isDebugEnabled()) {
> log.debug(" Calling hasUserDataPermission()");
> }
> Realm realm = this.context.getRealm();
> // Is this request URI subject to a security constraint?
> SecurityConstraint [] constraints
> = realm.findSecurityConstraints(request, this.context);
> if (!realm.hasUserDataPermission(request, response,
> constraints)) {
> if (log.isDebugEnabled()) {
> log.debug(" Failed hasUserDataPermission() test");
> }
> /*
> * ASSERT: Authenticator already set the appropriate
> * HTTP status code, so we do not have to do anything special
> */
> return;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
[jira] Updated: (BEEHIVE-635) Tomcat PageflowValve does not check for security-constraints defined in web.xml
Posted by "Abdessattar Sassi (JIRA)" <be...@incubator.apache.org>.
[ http://issues.apache.org/jira/browse/BEEHIVE-635?page=all ]
Abdessattar Sassi updated BEEHIVE-635:
--------------------------------------
Attachment: patch.txt
Attached in patch.txt is a SVN patch file to add the necessary code and fixes for the Tomcat adapter to work with Tomcat 5.5.7 or later.
Note that the patch requires that the catalina.jar and tomcat-coyote.jar in netui/external/tomcat/5x be updated from tomcat 5.5.7 at least (preferably 5.5.9).
> Tomcat PageflowValve does not check for security-constraints defined in web.xml
> -------------------------------------------------------------------------------
>
> Key: BEEHIVE-635
> URL: http://issues.apache.org/jira/browse/BEEHIVE-635
> Project: Beehive
> Type: Bug
> Components: NetUI
> Versions: V1Alpha, v1m1, V1Beta
> Environment: Using beehive latest from SVN and Tomcat 5.5.7
> Reporter: Abdessattar Sassi
> Fix For: TBD
> Attachments: patch.txt
>
> The Tomcat implementation of the Pipeline for a Context is such that only one Valve which is also an Authenticator valve is added to the Pipeline. The standard Tomcat Authenticator valves (e.g. BasicAuthenticator) check for and honor all the security constraints specified in the webapp web.xml descriptor.
> The PageflowValve implementation part of tomcat-server under netui is an Authenticaor valve as it extends BasicAuthenticator, which means that it is mutually exclusive with the regular Tomcat authenticator valves (only one can be in the pipeline). It does not however keep the features that were part of the AuthenticatorBase and the BasicAuthentiocator invoke() method implementation. Such issue results for example in the user-data-constraint elements being completely ignored, and therefore pages who are supposed to be served only with SSL are always served without SSL.
> Following is an example of the code from the regular Tomcat authenticators that is missing from beehive adapter (please note that the code is from Tomcat 5.5.7 with which by the way beehive does not compile, but should give you a good idea of the missing features...):
> // Enforce any user data constraint for this security constraint
> if (log.isDebugEnabled()) {
> log.debug(" Calling hasUserDataPermission()");
> }
> Realm realm = this.context.getRealm();
> // Is this request URI subject to a security constraint?
> SecurityConstraint [] constraints
> = realm.findSecurityConstraints(request, this.context);
> if (!realm.hasUserDataPermission(request, response,
> constraints)) {
> if (log.isDebugEnabled()) {
> log.debug(" Failed hasUserDataPermission() test");
> }
> /*
> * ASSERT: Authenticator already set the appropriate
> * HTTP status code, so we do not have to do anything special
> */
> return;
> }
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira