[Design of JBoss Web Services] - Re: WS4EE and AS5
by sguilhen@redhat.com
Alessio is right when he says the endpoint servlet is not called. Running the tests with TRACE enabled for org.jboss.security shows us the following:
| 2008-08-26 14:30:19,078 TRACE [org.jboss.security.plugins.authorization.JBossAuthorizationContext] (http-127.0.0.1-8080-1) Control flag for entry:org.jboss.security.authorization.config.AuthorizationModuleEntry{org.jboss.security.authorization.modules.JACCAuthorizationModule:{}required}is:[required]
| 2008-08-26 14:30:19,079 TRACE [org.jboss.security.authorization.modules.web.WebJACCPolicyModuleDelegate] (http-127.0.0.1-8080-1) resourceCheck=false : userDataCheck=true : roleRefCheck=false
| 2008-08-26 14:30:19,080 TRACE [org.jboss.security.authorization.modules.web.WebJACCPolicyModuleDelegate] (http-127.0.0.1-8080-1) hasUserDataPermission, p=(javax.security.jacc.WebUserDataPermission / POST)
| 2008-08-26 14:30:19,080 TRACE [org.jboss.security.jacc.ContextPolicy] (http-127.0.0.1-8080-1) No principals found in domain: ProtectionDomain null
| null
| <no principals>
| java.security.Permissions@1ed6d94 (
| (javax.security.jacc.EJBMethodPermission RoleSecuredSLSB)[*:*()]
| (javax.security.jacc.EJBMethodPermission BasicSecuredSLSB)[*:*()]
| [RoleSecuredSLSB,role-ref=friend]
| )
|
|
| 2008-08-26 14:30:19,080 TRACE [org.jboss.security.jacc.DelegatingPolicy] (http-127.0.0.1-8080-1) implied=false
| 2008-08-26 14:30:19,080 TRACE [org.jboss.security.authorization.modules.web.WebJACCPolicyModuleDelegate] (http-127.0.0.1-8080-1) Denied: (javax.security.jacc.WebUserDataPermission / POST)
| 2008-08-26 14:30:19,080 TRACE [org.jboss.security.plugins.authorization.JBossAuthorizationContext] (http-127.0.0.1-8080-1) Error in authorize:
| org.jboss.security.authorization.AuthorizationException: Authorization Failed:Denied.
| at org.jboss.security.plugins.authorization.JBossAuthorizationContext.invokeAuthorize(JBossAuthorizationContext.java:268)
| at org.jboss.security.plugins.authorization.JBossAuthorizationContext.access$000(JBossAuthorizationContext.java:67)
| at org.jboss.security.plugins.authorization.JBossAuthorizationContext$1.run(JBossAuthorizationContext.java:153)
| at java.security.AccessController.doPrivileged(Native Method)
| at org.jboss.security.plugins.authorization.JBossAuthorizationContext.authorize(JBossAuthorizationContext.java:149)
| at org.jboss.security.plugins.JBossAuthorizationManager.internalAuthorization(JBossAuthorizationManager.java:455)
| at org.jboss.security.plugins.JBossAuthorizationManager.authorize(JBossAuthorizationManager.java:121)
| at org.jboss.security.plugins.javaee.WebAuthorizationHelper.hasUserDataPermission(WebAuthorizationHelper.java:179)
| at org.jboss.web.tomcat.security.JBossWebRealm.hasUserDataPermission(JBossWebRealm.java:614)
| at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:461)
| at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:90)
| at org.jboss.web.tomcat.security.SecurityContextEstablishmentValve.invoke(SecurityContextEstablishmentValve.java:96)
| at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127)
| at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
| at org.jboss.web.tomcat.service.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:157)
| at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
| at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:325)
| at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:828)
| at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:601)
| at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:447)
| at java.lang.Thread.run(Thread.java:595)
| 2008-08-26 14:30:19,080 TRACE [org.jboss.security.plugins.javaee.WebAuthorizationHelper] (http-127.0.0.1-8080-1) hasRole check failed:Authorization Failed:Denied.
|
As we can see, JBossAuthorizationContext doesn't grant access to the endpoint servlet. So, either we have an incomplete policy or we are inappropriately performing authorization checks on this servlet.
anonymous wrote :
| Please note that it seems to me the ws calls are rejected in the same way even when using the right principal/credential
|
You are probably right here. The tests would fail even when using the right authentication info because access to the endpoint servlet would be rejected anyway.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172689#4172689
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172689
17 years, 7 months
[Design the new POJO MicroContainer] - Re: JBMICROCONT-336; empty string failure
by adrian@jboss.org
"alex.loubyansky(a)jboss.com" wrote : "adrian(a)jboss.org" wrote : "alex.loubyansky(a)jboss.com" wrote : adrian wrote : Maybe there should be some kind of @JBossXmlValue
| | | | annotation where we can say we want the empty string even for complex types.
| | |
| | | This alone doesn't make sense to me. I.e. the property could always be initialized to an empty string and if there was actual data it would override it.
| | |
| |
| | You could have the case (not this one) where you have a mixed
| | complex type and you want to know the value is ""
| |
|
| But with that annotation the value always will be "" (unless of course there is actual text data), won't it?
|
The raw text data will be "", but the mixed complex type
(if it is interested in it) might want to
do some kind of value adapter processing on it?
All I'm saying is that for a mixed complex type
| <blah/> is the same as <blah></blah>
|
which should pass "" through the @XmlValue setter processing.
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172638#4172638
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172638
17 years, 7 months
[Design the new POJO MicroContainer] - Re: JBoss with spaces in the directory name
by adrian@jboss.org
"dimitris(a)jboss.org" wrote : I want to create a new jboss-common-core release and saw the failing PropertyEditorsUnitTestCase so I changed it to agree with the changes in JBCOMMON-60 and make it pass.
|
| Can you guys check this is really how this is expected to behave?
I don't think you're patch is very good since you're basically
testing it against itself :-)
i.e. both the property editor and the test use Strings.toURx()
| - {new URL("http://www.jboss.org"), new File("/path with space/tst.xml").getCanonicalFile().toURL()},
| - {new URI("http://www.jboss.org"), new File("/path with space/tst.xml").getCanonicalFile().toURI()},
| + {new URL("http://www.jboss.org"), Strings.toURL("file:/path with space/tst.xml")},
| + {new URI("http://www.jboss.org"), Strings.toURI("file:/path with space/tst.xml")},
| {new String("JBoss, Home of Professional Open Source")},
|
The fix in JBCOMMON-60 was to make sure Strings.toURx() encoded the string
File.toURI() does, but File.toURL() does not.
http://java.sun.com/j2se/1.5.0/docs/api/java/io/File.html#toURL()
This little test program shows how it should work:
| import java.io.File;
| import java.net.URI;
| import java.net.URL;
|
| public class test
| {
| public static void main(String[] args) throws Exception
| {
| File file = new File("/path with space/tst.xml");
| URL url = file.getCanonicalFile().toURL();
| URI uri = file.getCanonicalFile().toURI();
| URL urlFromUri = uri.toURL();
|
| System.out.println("url = " + url + " WRONG!");
| System.out.println("uri = " + uri + " CORRECT");
| System.out.println("urlfromURI = " + urlFromUri + " ALSO CORRECT");
| }
| }
|
| url = file:/path with space/tst.xml WRONG!
| uri = file:/path%20with%20space/tst.xml CORRECT
| urlfromURI = file:/path%20with%20space/tst.xml ALSO CORRECT
|
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172632#4172632
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172632
17 years, 7 months
[Design of Messaging on JBoss (Messaging/JBoss)] - Re: JGroups Protocol Stack Configuration & Shunning Behavior
by jhowell@redhat.com
Yeah this seems like it could be an issue. Since we don't sync state upon reconnect automatically and do it manually, a customer has run into this issue.
They are dynamically changing their datasource(change and redeploy). When they do that it causes the jgroups channel to redeploy, which does away with the state. But since the post office is not restarting, the state is null and they get a null pointer exception. I'm going to enter a bug about this, which will probably be fixed with a depends in a strategic location, so that the post office redeploys with the rest of the application.
But it looks like that when a member gets shunned, they can't rejoin the cluster without a reboot. The problem with this is that the other channels behaves differently and doesn't have to be rebooted(JBCache, Default Partition, etc). This means that after a shun, all of the other channels can rejoin except for the JBM channels. Everything else will work except for JBM. It isn't clear at that point that the server has to be restarted. If we continue, we should add messages that redisply in a loop, "This JBM member has been shunned, a reboot is REQUIRED of this server".
Thoughts? Jay:)
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4172608#4172608
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4172608
17 years, 7 months