[JBoss JIRA] (WFLY-5618) HTTP Authentication Basic header is case sensitive
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-5618?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-5618:
--------------------------------------
Will be resolved once Undertow 1.3.17.Final makes its way in WF
> HTTP Authentication Basic header is case sensitive
> --------------------------------------------------
>
> Key: WFLY-5618
> URL: https://issues.jboss.org/browse/WFLY-5618
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 9.0.2.Final
> Environment: Wildfly 9.0.1.Final.
> Reporter: Karl Nicholas
> Assignee: Stuart Douglas
> Labels: authorization, http, security-constraint
>
> I wrote client code to login to a rest service with security-constraint. The client code must use an HTTP header of Authorization: Basic [Base 64 username:password]. If 'Basic' is sent as uppercase 'BASIC' it didn't work, but if sent as 'Basic' then it did work. I don't think the HTTP header fields should be case sensitive.
> https://tools.ietf.org/rfc/rfc2617.txt
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (WFLY-6157) Connection URL ignored for SQL Server datasource
by Rich DiCroce (JIRA)
Rich DiCroce created WFLY-6157:
----------------------------------
Summary: Connection URL ignored for SQL Server datasource
Key: WFLY-6157
URL: https://issues.jboss.org/browse/WFLY-6157
Project: WildFly
Issue Type: Bug
Affects Versions: 10.0.0.Final
Reporter: Rich DiCroce
Assignee: Jason Greene
The connection-url for a datasource is being ignored (or more likely, getting lost somewhere) when using WildFly with the Microsoft SQL Server JDBC driver. No matter what I specify as the connection-url (even something obviously invalid like "foobar"), the driver always ends up using the defaults that are baked into it.
The same driver worked fine on WildFly 10 CR2 (and many earlier versions), so some change between then and 10 Final has caused a regression.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (WFLY-6156) [Migration][WebToUndertow] JDBCAccessLogValve is not automatically migrated
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-6156?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet moved JBEAP-3322 to WFLY-6156:
------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6156 (was: JBEAP-3322)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (JBoss Web)
Web (Undertow)
(was: Web (Undertow))
(was: Migration)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.ER5)
> [Migration][WebToUndertow] JDBCAccessLogValve is not automatically migrated
> ---------------------------------------------------------------------------
>
> Key: WFLY-6156
> URL: https://issues.jboss.org/browse/WFLY-6156
> Project: WildFly
> Issue Type: Bug
> Components: Web (JBoss Web), Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: Stuart Douglas
> Priority: Minor
>
> In undertow there exists equivalent handler for {{org.apache.catalina.valves.JDBCAccessLogValve}} ({{io.undertow.server.handlers.JDBCLogHandler}}). As there is equivalent handler, the {{:migrate}} operation should handle its automatic migration.
> might be of interest to [~ehugonnet].
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (WFLY-6156) [Migration][WebToUndertow] JDBCAccessLogValve is not automatically migrated
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-6156?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet reassigned WFLY-6156:
---------------------------------------
Assignee: ehsavoie Hugonnet (was: Stuart Douglas)
> [Migration][WebToUndertow] JDBCAccessLogValve is not automatically migrated
> ---------------------------------------------------------------------------
>
> Key: WFLY-6156
> URL: https://issues.jboss.org/browse/WFLY-6156
> Project: WildFly
> Issue Type: Bug
> Components: Web (JBoss Web), Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Priority: Minor
>
> In undertow there exists equivalent handler for {{org.apache.catalina.valves.JDBCAccessLogValve}} ({{io.undertow.server.handlers.JDBCLogHandler}}). As there is equivalent handler, the {{:migrate}} operation should handle its automatic migration.
> might be of interest to [~ehugonnet].
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (WFLY-6155) [Migration][WebToUndertow] RemoteIpValve - protocolHeaderHttpsValue and proxiesHeader are neither migrated and neither migration warning is shown
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-6155?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet moved JBEAP-3325 to WFLY-6155:
------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6155 (was: JBEAP-3325)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (JBoss Web)
Web (Undertow)
(was: Web (Undertow))
(was: Migration)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.ER5)
> [Migration][WebToUndertow] RemoteIpValve - protocolHeaderHttpsValue and proxiesHeader are neither migrated and neither migration warning is shown
> -------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-6155
> URL: https://issues.jboss.org/browse/WFLY-6155
> Project: WildFly
> Issue Type: Bug
> Components: Web (JBoss Web), Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Priority: Critical
>
> When migrating {{RemoteIpValve}} which has defined params {{proxiesHeader}} and {{protocolHeaderHttpsValue}} these params are neither migrated nor migration warning is shown.
> If those params are not migratable, there should be printed at least migration warning for them.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (WFLY-6106) Exception is thrown during access, setting of cache in Infinispan in cluster with two nodes
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/WFLY-6106?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on WFLY-6106:
------------------------------------
Can you reproduce this with WildFly 10.0.0.Final?
> Exception is thrown during access, setting of cache in Infinispan in cluster with two nodes
> -------------------------------------------------------------------------------------------
>
> Key: WFLY-6106
> URL: https://issues.jboss.org/browse/WFLY-6106
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 9.0.1.Final
> Reporter: Serg Jakean19019
> Assignee: Paul Ferraro
> Attachments: logErrorsInfiniSpan.txt
>
>
> Exception is thrown during access and setting of cache in Infinispan. The error occurs not immediately.
> Konfiguration des CacheContainer:
> <cache-container name="customCache" default-cache="cachedb">
> <transport lock-timeout="60000"/>
> <replicated-cache name="cachedb" mode="SYNC">
> <locking isolation="READ_COMMITTED" striping="false" acquire-timeout="60000" concurrency-level="1000"/>
> <transaction mode="BATCH"/>
> <expiration lifespan="15000"/>
> </replicated-cache>
> </cache-container>
> Access of cache from Java:
> @Resource(lookup = "java:jboss/infinispan/container/customCache")
> private CacheContainer cc;
> private Map<String, Object> cache;
> public void setInInfiniSpan(String name, Object object) {
> Cache<Object,Object> cache = cc.getCache();
> TransactionManager tm = cache.getAdvancedCache().getTransactionManager();
> try {
> cache.startBatch();
> cache.put(name, object);
> cache.endBatch(true);
> } catch (SecurityException e) {
> // TODO Auto-generated catch block
> logger.error("SecurityException: "+e.getMessage(), e);
> } catch (IllegalStateException e) {
> // TODO Auto-generated catch block
> logger.error("IllegalStateException: "+e.getMessage(), e);
> }
> }
> Logs:
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (WFLY-6154) [Migration][WebToUndertow] RemoteAddrValve and RemoteHostValve are incorrectly migrated
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-6154?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet moved JBEAP-3323 to WFLY-6154:
------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6154 (was: JBEAP-3323)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (JBoss Web)
Web (Undertow)
(was: Web (Undertow))
(was: Migration)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.ER5)
> [Migration][WebToUndertow] RemoteAddrValve and RemoteHostValve are incorrectly migrated
> ---------------------------------------------------------------------------------------
>
> Key: WFLY-6154
> URL: https://issues.jboss.org/browse/WFLY-6154
> Project: WildFly
> Issue Type: Bug
> Components: Web (JBoss Web), Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Priority: Blocker
>
> When migrating {{RemoteHostValve}} or {{RemoteAddrValve}} which contains multiple allows or denies or contains both as in \[1\], it is migrated incorrectly. In the resulting expression the acl attribute should be in format {{acl=\{'xxx allow', 'yyy deny'\}}}, but instead it results in {{acl='xxx allow, yyy deny'}} which is incorrect and results in exception when doing any request to the server.
> Marking as critical as that it was migrated incorrectly the customer will not find out during migration but when actually doing request to the server.
> Might be interesting to [~ehugonnet]
> [1]
> {code:xml}
> <valve name="request-filter" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RemoteAddrValve">
> <param param-name="deny" param-value="10.0.0.1"/>
> <param param-name="allow" param-value="127.*"/>
> </valve>
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (WFLY-6153) [Migration][WebToUndertow] RemoteIpValve is not correctly migrated
by ehsavoie Hugonnet (JIRA)
[ https://issues.jboss.org/browse/WFLY-6153?page=com.atlassian.jira.plugin.... ]
ehsavoie Hugonnet moved JBEAP-3321 to WFLY-6153:
------------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-6153 (was: JBEAP-3321)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Web (JBoss Web)
Web (Undertow)
(was: Web (Undertow))
(was: Migration)
Target Release: (was: 7.0.0.GA)
Affects Version/s: 10.0.0.Final
(was: 7.0.0.ER5)
> [Migration][WebToUndertow] RemoteIpValve is not correctly migrated
> ------------------------------------------------------------------
>
> Key: WFLY-6153
> URL: https://issues.jboss.org/browse/WFLY-6153
> Project: WildFly
> Issue Type: Bug
> Components: Web (JBoss Web), Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: ehsavoie Hugonnet
> Assignee: ehsavoie Hugonnet
> Priority: Blocker
>
> When migrating RemoteIpValve which looks like this
> {code:xml}
> <valve name="remote-ip-valve" module="org.jboss.as.web" class-name="org.apache.catalina.valves.RemoteIpValve">
> <param param-name="httpServerPort" param-value="8080"/>
> <param param-name="httpsServerPort" param-value="8443"/>
> <param param-name="internalProxies" param-value="192.*|127.*"/>
> <param param-name="trustedProxies" param-value="10.*"/>
> <param param-name="protocolHeaderHttpsValue" param-value="https"/>
> <param param-name="protocolHeader" param-value="X-Forwarded-Proto"/>
> <param param-name="remoteIpHeader" param-value="X-Forwarded-For"/>
> <param param-name="proxiesHeader" param-value="X-Forwarded-By"/>
> </valve>
> {code}
> it is migrated to expression filter looking like this
> {noformat}
> <expression-filter expression="regexp(pattern="10.*", value=%{i, x-forwarded-for}, full-match=true) and regexp(pattern="192.*|127.*", value=%{i, x-forwarded-for}, full-match=true) -> { proxy-peer-address(); }" name="remote-ip-valve"/>
> {noformat}
> When doing request to http://127.0.0.1:8080/ it fails with 500 and this exception in log
> {noformat}
> 14:06:53,648 ERROR [io.undertow.request] (default I/O-4) UT005071: Undertow request failed HttpServerExchange{ GET / request {Accept=[*/*], User-Agent=[curl/7.43.0-DEV], Host=[127.0.0.1:8080]} response {}}: java.lang.IllegalArgumentException: UT000045: Error parsing predicated handler string Expecting , or ):
> regexp(pattern="10.*", value=%{i, x-forwarded-for}, full-match=true) and regexp(pattern="192.*|127.*", value=%{i, x-forwarded-for}, full-match=true) -> { proxy-peer-address(); }
> ^
> at io.undertow.server.handlers.builder.PredicatedHandlersParser.error(PredicatedHandlersParser.java:727)
> at io.undertow.server.handlers.builder.PredicatedHandlersParser.parseExpression(PredicatedHandlersParser.java:506)
> at io.undertow.server.handlers.builder.PredicatedHandlersParser.parse(PredicatedHandlersParser.java:381)
> at io.undertow.server.handlers.builder.PredicatedHandlersParser.parse(PredicatedHandlersParser.java:322)
> at io.undertow.server.handlers.builder.PredicatedHandlersParser.parse(PredicatedHandlersParser.java:85)
> at org.wildfly.extension.undertow.filters.ExpressionFilterDefinition.createHttpHandler(ExpressionFilterDefinition.java:88)
> at org.wildfly.extension.undertow.filters.FilterService.createHttpHandler(FilterService.java:57)
> at org.wildfly.extension.undertow.filters.FilterRef.createHttpHandler(FilterRef.java:69)
> at org.wildfly.extension.undertow.LocationService.configureHandlerChain(LocationService.java:96)
> at org.wildfly.extension.undertow.Host.configureRootHandler(Host.java:117)
> at org.wildfly.extension.undertow.Host.getOrCreateRootHandler(Host.java:171)
> at org.wildfly.extension.undertow.Host$HostRootHandler.handleRequest(Host.java:285)
> at io.undertow.server.handlers.NameVirtualHostHandler.handleRequest(NameVirtualHostHandler.java:64)
> at io.undertow.server.handlers.error.SimpleErrorPageHandler.handleRequest(SimpleErrorPageHandler.java:76)
> at io.undertow.server.handlers.CanonicalPathHandler.handleRequest(CanonicalPathHandler.java:49)
> at io.undertow.server.handlers.ChannelUpgradeHandler.handleRequest(ChannelUpgradeHandler.java:158)
> at io.undertow.server.Connectors.executeRootHandler(Connectors.java:202)
> at io.undertow.server.protocol.http.HttpReadListener.handleEventWithNoRunningRequest(HttpReadListener.java:233)
> at io.undertow.server.protocol.http.HttpReadListener.handleEvent(HttpReadListener.java:131)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:145)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:92)
> at io.undertow.server.protocol.http.HttpOpenListener.handleEvent(HttpOpenListener.java:51)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:291)
> at org.xnio.ChannelListeners$10.handleEvent(ChannelListeners.java:286)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.nio.QueuedNioTcpServer$1.run(QueuedNioTcpServer.java:121)
> at org.xnio.nio.WorkerThread.safeRun(WorkerThread.java:580)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:464)
> {noformat}
> The exception is caused by not having in quotes the '%\{i, x-forwarded-for\}'.
> Also there is no predicate named {{regexp}}, the correct name is {{regex}}.
> As this is hidden to the customer during the migration operation and is not visible before customer sends request to the server marking as blocker.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
[JBoss JIRA] (WFLY-6152) EJB timer scheduler log an Exception for an already canceled timer
by RH Bugzilla Integration (JIRA)
[ https://issues.jboss.org/browse/WFLY-6152?page=com.atlassian.jira.plugin.... ]
RH Bugzilla Integration updated WFLY-6152:
------------------------------------------
Bugzilla References: https://bugzilla.redhat.com/show_bug.cgi?id=1305960
Bugzilla Update: Perform
> EJB timer scheduler log an Exception for an already canceled timer
> ------------------------------------------------------------------
>
> Key: WFLY-6152
> URL: https://issues.jboss.org/browse/WFLY-6152
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 8.0.0.Final
> Reporter: Wolf-Dieter Fink
> Assignee: Wolf-Dieter Fink
> Priority: Minor
> Labels: timer, timers, timerservice
>
> If a timer is canceled inside of the @timeout method the scheduler will log an ERROR if the timer duration is longer than the intervall and an overlapping execution should be fired.
> This is due to internal validatons.
> This will not happen if the timer is canceled by an external process, here the scheduler is removed.
> The log message is like this:
> ERROR [org.jboss.as.ejb3] (EJB default - 3) WFLYEJB0164: Exception running timer task for timer [id=0bd9870b-568b-42f5-9bda-e1525c3500aa timedObjectId=ejb30-timer.ejb30-timer.SimpleTimerBean auto-timer?:false persistent?:true timerService=org.jboss.as.ejb3.timerservice.TimerServiceImpl@53ba1a7f initialExpiration=Tue Feb 09 17:19:32 CET 2016 intervalDuration(in milli sec)=5000 nextExpiration=Tue Feb 09 17:19:37 CET 2016 timerState=CANCELED info=SimpleTimerInfo description=A timer started every 5 seconds] on EJB ejb30-timer.ejb30-timer.SimpleTimerBean: javax.ejb.NoSuchObjectLocalException: WFLYEJB0331: Timer was canceled
> at org.jboss.as.ejb3.timerservice.TimerImpl.assertTimerState(TimerImpl.java:459)
> at org.jboss.as.ejb3.timerservice.TimerImpl.isPersistent(TimerImpl.java:215)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl.shouldRun(TimerServiceImpl.java:1117)
> at org.jboss.as.ejb3.timerservice.TimerTask.run(TimerTask.java:124)
> at org.jboss.as.ejb3.timerservice.TimerServiceImpl$Task$1.run(TimerServiceImpl.java:1221)
> at org.wildfly.extension.requestcontroller.RequestController$QueuedTask$1.run(RequestController.java:497)
> 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)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
8 years, 9 months
