[JBoss JIRA] (WFLY-7716) Added tests for XA DataSource statistics
by Daniel Simko (JIRA)
Daniel Simko created WFLY-7716:
----------------------------------
Summary: Added tests for XA DataSource statistics
Key: WFLY-7716
URL: https://issues.jboss.org/browse/WFLY-7716
Project: WildFly
Issue Type: Enhancement
Components: Test Suite
Reporter: Daniel Simko
Assignee: Daniel Simko
Priority: Minor
Added new testcase for testing xa-data-source's pool statistics (XACommitCount, XARollbackCount, XAStartCount).
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFCORE-2074) [GSS] (7.1.0) Servlet does not have permissions to read parent resources when deployed in EAR
by Ivo Studensky (JIRA)
Ivo Studensky created WFCORE-2074:
-------------------------------------
Summary: [GSS] (7.1.0) Servlet does not have permissions to read parent resources when deployed in EAR
Key: WFCORE-2074
URL: https://issues.jboss.org/browse/WFCORE-2074
Project: WildFly Core
Issue Type: Bug
Components: Server
Reporter: Ivo Studensky
Assignee: Ivo Studensky
Servlet is provided with VFS mount points to be able to read resources from any library submodule packed in an EAR, but it does not have VirtualFilePermissions to do so when running with Security Manager enabled. This leads to the situation when the parent module corresponding to the EAR deployment does have VirtualFilePermissions to read resources from libraries packed in the deployment, but web submodules cannot reach them. Web submodules are provided only with permissions to its own resources like WEB-INF/classes etc. and they are missing the parent module permissions. See the following stack trace:
*Stacktrace*
{code}
ERROR [io.undertow.request] (default task-3) UT005023: Exception handling request to /deployment0/EarServlet: java.security.AccessControlException: WFSM000001: Permission check failed (permission "("org.jboss.vfs.VirtualFilePermission" "/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/5d904ae0/testsuite/integration/basic/target/exploded_deployments/eardeployment2.ear/lib/lib.jar/jar-info.txt" "read")" in code source "(vfs:/mnt/hudson_workspace/workspace/eap-7x-as-testsuite-test-integ-rhel-secman/5d904ae0/testsuite/integration/basic/target/exploded_deployments/eardeployment2.ear/deployment0.war/WEB-INF/classes <no signer certificates>)" of "null")
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:273)
at org.wildfly.security.manager.WildFlySecurityManager.checkPermission(WildFlySecurityManager.java:175)
at org.jboss.vfs.VirtualFile.openStream(VirtualFile.java:253)
at org.jboss.as.server.deployment.module.VFSResourceLoader$VFSEntryResource.openStream(VFSResourceLoader.java:327)
at org.jboss.modules.Module.getResourceAsStream(Module.java:674)
at org.jboss.modules.ModuleClassLoader.findResourceAsStream(ModuleClassLoader.java:546)
at org.jboss.modules.ConcurrentClassLoader.getResourceAsStream(ConcurrentClassLoader.java:321)
at org.jboss.as.test.integration.management.cli.EarServlet.doGet(EarServlet.java:19)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:687)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:790)
at io.undertow.servlet.handlers.ServletHandler.handleRequest(ServletHandler.java:85)
at io.undertow.servlet.handlers.security.ServletSecurityRoleHandler.handleRequest(ServletSecurityRoleHandler.java:62)
at io.undertow.servlet.handlers.ServletDispatchingHandler.handleRequest(ServletDispatchingHandler.java:36)
at org.wildfly.extension.undertow.security.SecurityContextAssociationHandler.handleRequest(SecurityContextAssociationHandler.java:78)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.security.SSLInformationAssociationHandler.handleRequest(SSLInformationAssociationHandler.java:131)
at io.undertow.servlet.handlers.security.ServletAuthenticationCallHandler.handleRequest(ServletAuthenticationCallHandler.java:57)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.security.handlers.AbstractConfidentialityHandler.handleRequest(AbstractConfidentialityHandler.java:46)
at io.undertow.servlet.handlers.security.ServletConfidentialityConstraintHandler.handleRequest(ServletConfidentialityConstraintHandler.java:64)
at io.undertow.security.handlers.AuthenticationMechanismsHandler.handleRequest(AuthenticationMechanismsHandler.java:60)
at io.undertow.servlet.handlers.security.CachedAuthenticatedSessionHandler.handleRequest(CachedAuthenticatedSessionHandler.java:77)
at io.undertow.security.handlers.NotificationReceiverHandler.handleRequest(NotificationReceiverHandler.java:50)
at io.undertow.security.handlers.AbstractSecurityContextAssociationHandler.handleRequest(AbstractSecurityContextAssociationHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at org.wildfly.extension.undertow.security.jacc.JACCContextIdHandler.handleRequest(JACCContextIdHandler.java:61)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.server.handlers.PredicateHandler.handleRequest(PredicateHandler.java:43)
at io.undertow.servlet.handlers.ServletInitialHandler.handleFirstRequest(ServletInitialHandler.java:284)
at io.undertow.servlet.handlers.ServletInitialHandler.dispatchRequest(ServletInitialHandler.java:263)
at io.undertow.servlet.handlers.ServletInitialHandler.access$000(ServletInitialHandler.java:81)
at io.undertow.servlet.handlers.ServletInitialHandler$1$1.run(ServletInitialHandler.java:180)
at java.security.AccessController.doPrivileged(Native Method)
at io.undertow.servlet.handlers.ServletInitialHandler$1.handleRequest(ServletInitialHandler.java:177)
at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
at io.undertow.server.HttpServerExchange$1.run(HttpServerExchange.java:793)
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
at java.lang.Thread.run(Thread.java:745)
{code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-7715) wildfly-service.exe and jbosspass wrong with # inside
by Seb Dk (JIRA)
[ https://issues.jboss.org/browse/WFLY-7715?page=com.atlassian.jira.plugin.... ]
Seb Dk updated WFLY-7715:
-------------------------
Description:
Hi there,
I am installing wildfy 10.1.0 as service on a win 20012 server.
It is working but I cannot stop the service.
I figured out where the problem is coming from.
When I installe Wildly as a service, I run the following command:
E:\Products\wildfly-10.1.0.Final\bin\service>service.bat install /serviceuser .\JBoss /servicepass my#pass /controller localhost:9991 /jbossuser myuser /jbosspass *my#pass*
But I can see whe I am trying to stop the service, the command running is:
E:\Products\wildfly-10.1.0.Final\bin\jboss-cli.bat --controller=localhost:9991 --connect --user=myuser --password=*my" "pass* --command=:shutdown
Any workaround?
Thanks,
S.
was:
Hi there,
I am installing wildfy 10.1.0 as service on a win 20012 server.
It is working but I cannot stop the service.
I figured out where the problem is coming from.
When I installe Wildly as a service, I run the following command:
E:\Products\wildfly-10.1.0.Final\bin\service>service.bat install /serviceuser .\JBoss /servicepass my#pass /controller localhost:9991 /jbossuser myuser /jbosspass my#pass
But I can see whe I am trying to stop the service, the command running is:
E:\Products\wildfly-10.1.0.Final\bin\jboss-cli.bat --controller=localhost:9991 --connect --user=myuser --password=my" "pass --command=:shutdown
Any workaround?
Thanks,
S.
> wildfly-service.exe and jbosspass wrong with # inside
> -----------------------------------------------------
>
> Key: WFLY-7715
> URL: https://issues.jboss.org/browse/WFLY-7715
> Project: WildFly
> Issue Type: Bug
> Reporter: Seb Dk
> Assignee: Jason Greene
>
> Hi there,
>
> I am installing wildfy 10.1.0 as service on a win 20012 server.
> It is working but I cannot stop the service.
> I figured out where the problem is coming from.
>
> When I installe Wildly as a service, I run the following command:
> E:\Products\wildfly-10.1.0.Final\bin\service>service.bat install /serviceuser .\JBoss /servicepass my#pass /controller localhost:9991 /jbossuser myuser /jbosspass *my#pass*
>
> But I can see whe I am trying to stop the service, the command running is:
> E:\Products\wildfly-10.1.0.Final\bin\jboss-cli.bat --controller=localhost:9991 --connect --user=myuser --password=*my" "pass* --command=:shutdown
>
> Any workaround?
>
> Thanks,
>
> S.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-7715) wildfly-service.exe and jbosspass wrong with # inside
by Seb Dk (JIRA)
[ https://issues.jboss.org/browse/WFLY-7715?page=com.atlassian.jira.plugin.... ]
Seb Dk updated WFLY-7715:
-------------------------
Issue Type: Bug (was: Feature Request)
> wildfly-service.exe and jbosspass wrong with # inside
> -----------------------------------------------------
>
> Key: WFLY-7715
> URL: https://issues.jboss.org/browse/WFLY-7715
> Project: WildFly
> Issue Type: Bug
> Reporter: Seb Dk
> Assignee: Jason Greene
>
> Hi there,
>
> I am installing wildfy 10.1.0 as service on a win 20012 server.
> It is working but I cannot stop the service.
> I figured out where the problem is coming from.
>
> When I installe Wildly as a service, I run the following command:
> E:\Products\wildfly-10.1.0.Final\bin\service>service.bat install /serviceuser .\JBoss /servicepass my#pass /controller localhost:9991 /jbossuser myuser /jbosspass my#pass
>
> But I can see whe I am trying to stop the service, the command running is:
> E:\Products\wildfly-10.1.0.Final\bin\jboss-cli.bat --controller=localhost:9991 --connect --user=myuser --password=my" "pass --command=:shutdown
>
> Any workaround?
>
> Thanks,
>
> S.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-7715) wildfly-service.exe and jbosspass wrong with # inside
by Seb Dk (JIRA)
Seb Dk created WFLY-7715:
----------------------------
Summary: wildfly-service.exe and jbosspass wrong with # inside
Key: WFLY-7715
URL: https://issues.jboss.org/browse/WFLY-7715
Project: WildFly
Issue Type: Feature Request
Reporter: Seb Dk
Assignee: Jason Greene
Hi there,
I am installing wildfy 10.1.0 as service on a win 20012 server.
It is working but I cannot stop the service.
I figured out where the problem is coming from.
When I installe Wildly as a service, I run the following command:
E:\Products\wildfly-10.1.0.Final\bin\service>service.bat install /serviceuser .\JBoss /servicepass my#pass /controller localhost:9991 /jbossuser myuser /jbosspass my#pass
But I can see whe I am trying to stop the service, the command running is:
E:\Products\wildfly-10.1.0.Final\bin\jboss-cli.bat --controller=localhost:9991 --connect --user=myuser --password=my" "pass --command=:shutdown
Any workaround?
Thanks,
S.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months
[JBoss JIRA] (WFLY-7662) CLIENT-CERT authentication doesn't work
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-7662?page=com.atlassian.jira.plugin.... ]
Stuart Douglas resolved WFLY-7662.
----------------------------------
Resolution: Rejected
There is nothing we can do about this. The HTTP/2 spec says:
9.2.1. TLS 1.2 Features
A deployment of HTTP/2 over TLS 1.2 MUST disable renegotiation. An
endpoint MUST treat a TLS renegotiation as a connection error
(Section 5.4.1) of type PROTOCOL_ERROR.
and
This effectively prevents the use of renegotiation in response to a
request for a specific protected resource. A future specification
might provide a way to support this use case. Alternatively, a
server might use an error (Section 5.4) of type HTTP_1_1_REQUIRED to
request the client use a protocol that supports renegotiation.
However it looks like the HTTP_1_1_REQUIRED response is not honored by firefox or chrome.
> CLIENT-CERT authentication doesn't work
> ---------------------------------------
>
> Key: WFLY-7662
> URL: https://issues.jboss.org/browse/WFLY-7662
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 10.1.0.Final
> Environment: Java 1.8.0_112
> Reporter: Rostyslav Smirnov
> Assignee: Stuart Douglas
>
> When accessing a web application secured by CLIENT-CERT authentication, a browser no longer presents certificate dialog prompt, always displays response 403 Forbidden instead.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
8 years, 11 months