[JBoss JIRA] (WFLY-3987) Regression regarding WS Client when using header authentication
by Pushpak Sathyanarayan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3987?page=com.atlassian.jira.plugin.... ]
Pushpak Sathyanarayan commented on WFLY-3987:
---------------------------------------------
Hello [~wildmdc]
Can you please help me out this work around?even I m facing the similar issue in wildfly 8.2 .
Thanks,
Pushpak
> Regression regarding WS Client when using header authentication
> ---------------------------------------------------------------
>
> Key: WFLY-3987
> URL: https://issues.jboss.org/browse/WFLY-3987
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.1.0.Final, 9.0.0.Alpha1
> Environment: Linux (Ubuntu 14.04), OpenJDK 1.7.0_65, Wildfly 8.0/8.1/9.0A
> Reporter: Marcus Carlson
> Assignee: Alessio Soldano
>
> I'm trying to integrate a Web Service client based on BMC Remedy product where Web service authentication is handled in Soap Header and not basic authentication. See AuthenticationInfo element on https://github.com/macmorning/itsm_mobileview/blob/master/SoapUI%20Projec... for an example of how the WSDL file looks like.
> I've enabled Xadditionalheaders so I get the AuthenticationInfo as the last argument, like this:
> {noformat}
> port.helpDeskQueryListService(qualification, startRecord, maxLimit, authInfo);
> {noformat}
> Problem is that this was working fine in WildFly 8.0 generating the following SOAP Request:
> {noformat}
> ID: 1
> Address: https://SERVER/arsys/services/ARService?server=SERVER&webService=HPD_Inci...
> Encoding: UTF-8
> Http-Method: POST
> Content-Type: text/xml
> Headers: {Accept=[*/*], SOAPAction=["urn:HPD_IncidentInterface_WS/HelpDesk_QueryList_Service"]}
> Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><AuthenticationInfo xmlns="urn:HPD_IncidentInterface_WS"><userName>SECRETUSER</userName><password>SECRETPASSWORD</password></AuthenticationInfo></soap:Header><soap:Body><HelpDesk_QueryList_Service xmlns="urn:HPD_IncidentInterface_WS"><Qualification>'Status' = "Closed"</Qualification><startRecord>0</startRecord><maxLimit>1000</maxLimit></HelpDesk_QueryList_Service></soap:Body></soap:Envelope>
> {noformat}
> With 8.1 it's generating a completly different payload with the Header element in Body and body completly missing (!):
> {noformat}
> ID: 2
> Address: https://SERVER/arsys/services/ARService?server=SERVER&webService=HPD_Inci...
> Encoding: UTF-8
> Http-Method: POST
> Content-Type: text/xml
> Headers: {Accept=[*/*], SOAPAction=["urn:HPD_IncidentInterface_WS/HelpDesk_QueryList_Service"]}
> Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><HelpDesk_QueryList_Service xmlns="urn:HPD_IncidentInterface_WS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="AuthenticationInfo"><userName>SECRETUSER</userName><password>SECRETPASSWORD</password></HelpDesk_QueryList_Service></soap:Body></soap:Envelope>
> {noformat}
> I've also tried 9.0.0.Alpha1 with same result. What could be wrong?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (WFLY-3987) Regression regarding WS Client when using header authentication
by Pushpak Sathyanarayan (JIRA)
[ https://issues.jboss.org/browse/WFLY-3987?page=com.atlassian.jira.plugin.... ]
Pushpak Sathyanarayan edited comment on WFLY-3987 at 11/18/16 5:45 AM:
-----------------------------------------------------------------------
Hello [~wildmdc]
Can you please help me out on this work around?even I m facing the similar issue in wildfly 8.2 .
Thanks,
Pushpak
was (Author: push174):
Hello [~wildmdc]
Can you please help me out this work around?even I m facing the similar issue in wildfly 8.2 .
Thanks,
Pushpak
> Regression regarding WS Client when using header authentication
> ---------------------------------------------------------------
>
> Key: WFLY-3987
> URL: https://issues.jboss.org/browse/WFLY-3987
> Project: WildFly
> Issue Type: Bug
> Components: Web Services
> Affects Versions: 8.1.0.Final, 9.0.0.Alpha1
> Environment: Linux (Ubuntu 14.04), OpenJDK 1.7.0_65, Wildfly 8.0/8.1/9.0A
> Reporter: Marcus Carlson
> Assignee: Alessio Soldano
>
> I'm trying to integrate a Web Service client based on BMC Remedy product where Web service authentication is handled in Soap Header and not basic authentication. See AuthenticationInfo element on https://github.com/macmorning/itsm_mobileview/blob/master/SoapUI%20Projec... for an example of how the WSDL file looks like.
> I've enabled Xadditionalheaders so I get the AuthenticationInfo as the last argument, like this:
> {noformat}
> port.helpDeskQueryListService(qualification, startRecord, maxLimit, authInfo);
> {noformat}
> Problem is that this was working fine in WildFly 8.0 generating the following SOAP Request:
> {noformat}
> ID: 1
> Address: https://SERVER/arsys/services/ARService?server=SERVER&webService=HPD_Inci...
> Encoding: UTF-8
> Http-Method: POST
> Content-Type: text/xml
> Headers: {Accept=[*/*], SOAPAction=["urn:HPD_IncidentInterface_WS/HelpDesk_QueryList_Service"]}
> Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Header><AuthenticationInfo xmlns="urn:HPD_IncidentInterface_WS"><userName>SECRETUSER</userName><password>SECRETPASSWORD</password></AuthenticationInfo></soap:Header><soap:Body><HelpDesk_QueryList_Service xmlns="urn:HPD_IncidentInterface_WS"><Qualification>'Status' = "Closed"</Qualification><startRecord>0</startRecord><maxLimit>1000</maxLimit></HelpDesk_QueryList_Service></soap:Body></soap:Envelope>
> {noformat}
> With 8.1 it's generating a completly different payload with the Header element in Body and body completly missing (!):
> {noformat}
> ID: 2
> Address: https://SERVER/arsys/services/ARService?server=SERVER&webService=HPD_Inci...
> Encoding: UTF-8
> Http-Method: POST
> Content-Type: text/xml
> Headers: {Accept=[*/*], SOAPAction=["urn:HPD_IncidentInterface_WS/HelpDesk_QueryList_Service"]}
> Payload: <soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><soap:Body><HelpDesk_QueryList_Service xmlns="urn:HPD_IncidentInterface_WS" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:type="AuthenticationInfo"><userName>SECRETUSER</userName><password>SECRETPASSWORD</password></HelpDesk_QueryList_Service></soap:Body></soap:Envelope>
> {noformat}
> I've also tried 9.0.0.Alpha1 with same result. What could be wrong?
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (WFLY-7621) Unable to access http management interface secured by legacy ldap realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-7621?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse reassigned WFLY-7621:
--------------------------------------
Assignee: Darran Lofthouse
> Unable to access http management interface secured by legacy ldap realm
> -----------------------------------------------------------------------
>
> Key: WFLY-7621
> URL: https://issues.jboss.org/browse/WFLY-7621
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Assignee: Darran Lofthouse
> Priority: Blocker
>
> When http management interface is secured with legacy security realm using ldap, user is not prompted to provide credentials as should be in case of BASIC http authentication mechanism. Instead {{403}} http status is returned directly.
> Users won't be able to migrate their current (6.4, 7.0) configuration to 7.1 without change.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (WFLY-7621) Unable to access http management interface secured by legacy ldap realm
by Martin Choma (JIRA)
[ https://issues.jboss.org/browse/WFLY-7621?page=com.atlassian.jira.plugin.... ]
Martin Choma moved JBEAP-7394 to WFLY-7621:
-------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-7621 (was: JBEAP-7394)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Security
(was: Security)
Affects Version/s: 11.0.0.Alpha1
(was: 7.1.0.DR8)
> Unable to access http management interface secured by legacy ldap realm
> -----------------------------------------------------------------------
>
> Key: WFLY-7621
> URL: https://issues.jboss.org/browse/WFLY-7621
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 11.0.0.Alpha1
> Reporter: Martin Choma
> Priority: Blocker
>
> When http management interface is secured with legacy security realm using ldap, user is not prompted to provide credentials as should be in case of BASIC http authentication mechanism. Instead {{403}} http status is returned directly.
> Users won't be able to migrate their current (6.4, 7.0) configuration to 7.1 without change.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (WFCORE-2011) Inconsistency of formatter and named-formatter in console logging handler
by ted won (JIRA)
[ https://issues.jboss.org/browse/WFCORE-2011?page=com.atlassian.jira.plugi... ]
ted won updated WFCORE-2011:
----------------------------
Description:
In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter.
And the COLOR-PATTERN named-formatter is defined with {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n".{noformat}
It is working as it is defined with colors.
{code:title=standalone.xml}
...
<subsystem xmlns="urn:jboss:domain:logging:3.0">
<console-handler name="CONSOLE">
<level name="INFO"/>
<formatter>
<named-formatter name="COLOR-PATTERN"/>
</formatter>
</console-handler>
...
<formatter name="COLOR-PATTERN">
<pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
</formatter>
</subsystem>
...
{code}
However there is a inconsistency in the CLI and WildFly admin console views.
{noformat}
In the CLI, CONSOLE formatter is "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n". It is different with the working logging format.
{noformat}
{code:title=JBoss CLI}
[standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
{
"outcome" => "success",
"result" => {
"autoflush" => true,
"enabled" => true,
"encoding" => undefined,
"filter" => undefined,
"filter-spec" => undefined,
"formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n",
"level" => "INFO",
"name" => "CONSOLE",
"named-formatter" => "COLOR-PATTERN",
"target" => "System.out"
}
}
{code}
was:
In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter.
And the COLOR-PATTERN named-formatter is defined with {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n".{noformat}
It is working as it is defined with colors.
{code:title=standalone.xml}
...
<subsystem xmlns="urn:jboss:domain:logging:3.0">
<console-handler name="CONSOLE">
<level name="INFO"/>
<formatter>
<named-formatter name="COLOR-PATTERN"/>
</formatter>
</console-handler>
...
<formatter name="COLOR-PATTERN">
<pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
</formatter>
</subsystem>
...
{code}
However there is a inconsistency in the CLI and WildFly admin console views.
{noformat}
In the CLI, CONSOLE formatter is "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n". It is different with the working logging format.
{noformat}
{code:title=JBoss CLI}
[standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
{
"outcome" => "success",
"result" => {
"autoflush" => true,
"enabled" => true,
"encoding" => undefined,
"filter" => undefined,
"filter-spec" => undefined,
"formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n",
"level" => "INFO",
"name" => "CONSOLE",
"named-formatter" => "COLOR-PATTERN",
"target" => "System.out"
}
}
{code}
It is possible to reproduce with all profiles and all modes.
* standalone.xml
* standalone-full-ha.xml
* standalone mode
* domain mode
Environment:
It is possible to reproduce with all profiles and all modes.
All WildFly profiles
All WildFly clustering mode
* standalone mode
* domain mode
> Inconsistency of formatter and named-formatter in console logging handler
> -------------------------------------------------------------------------
>
> Key: WFCORE-2011
> URL: https://issues.jboss.org/browse/WFCORE-2011
> Project: WildFly Core
> Issue Type: Bug
> Components: Logging
> Affects Versions: 3.0.0.Alpha13
> Environment: It is possible to reproduce with all profiles and all modes.
> All WildFly profiles
> All WildFly clustering mode
> * standalone mode
> * domain mode
> Reporter: ted won
> Assignee: ted won
> Priority: Minor
> Labels: logging
> Attachments: COLOR-PATTERN.png, CONSOLE-console-handler.png
>
>
> In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter.
> And the COLOR-PATTERN named-formatter is defined with {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n".{noformat}
> It is working as it is defined with colors.
> {code:title=standalone.xml}
> ...
> <subsystem xmlns="urn:jboss:domain:logging:3.0">
> <console-handler name="CONSOLE">
> <level name="INFO"/>
> <formatter>
> <named-formatter name="COLOR-PATTERN"/>
> </formatter>
> </console-handler>
> ...
> <formatter name="COLOR-PATTERN">
> <pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
> </formatter>
> </subsystem>
> ...
> {code}
> However there is a inconsistency in the CLI and WildFly admin console views.
> {noformat}
> In the CLI, CONSOLE formatter is "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n". It is different with the working logging format.
> {noformat}
> {code:title=JBoss CLI}
> [standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
> {
> "outcome" => "success",
> "result" => {
> "autoflush" => true,
> "enabled" => true,
> "encoding" => undefined,
> "filter" => undefined,
> "filter-spec" => undefined,
> "formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n",
> "level" => "INFO",
> "name" => "CONSOLE",
> "named-formatter" => "COLOR-PATTERN",
> "target" => "System.out"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (WFLY-7210) Expose JAX-RS resources as children of the subsystem
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFLY-7210?page=com.atlassian.jira.plugin.... ]
Lin Gao commented on WFLY-7210:
-------------------------------
Each root REST resource class(the class with annotation {{@Path}}) will be a child resource in management model, this is the only level of child resource added in management model for this. There is NO child resource defined for each method(with REST annotations like: @GET, @Path, etc) defined in this class. The {{rest-resource-paths}} and {{sub-resource-locators}} are metrics attributes of ModelNode type: LIST.
I wrote a page for the example, would you please take a look at here: https://github.com/gaol/quickstart/wiki/WFLY-7024-REST-resource-example ?
I don't know whether my concern about too many child resources makes sense or not, I am open to any suggestions. :) If the effort made to display more user friendly UI in web console is small, I think it would be good to do there, otherwise, I can try with another level of child resource for this. :)
> Expose JAX-RS resources as children of the subsystem
> ----------------------------------------------------
>
> Key: WFLY-7210
> URL: https://issues.jboss.org/browse/WFLY-7210
> Project: WildFly
> Issue Type: Feature Request
> Components: REST
> Affects Versions: 10.1.0.Final
> Reporter: Guillermo González de Agüero
> Assignee: Lin Gao
> Attachments: after-wfly7024.png, hal-jaxrs.png
>
>
> Servlets, EJBs, WebSockets, JPA, etc expose its components as children of the subsystem in the management API. For example to list the stateless EJBs of a deployment:
> [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=ejb3:read-children-resources(child-type=stateless-session-bean)
> This makes it specially easy to navigate trough the web console (attached screenshot).
> To read JAX-RS resources, the command would be:
> [standalone@localhost:9990 /] /deployment=cdivsejb.war/subsystem=jaxrs:show-resources()
> I propose to make deprecate the show-resources operation and create a new "resources" child, containing the Rest resources.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (WFCORE-2012) Inconsistency of formatter and named-formatter in console logging handler
by ted won (JIRA)
ted won created WFCORE-2012:
-------------------------------
Summary: Inconsistency of formatter and named-formatter in console logging handler
Key: WFCORE-2012
URL: https://issues.jboss.org/browse/WFCORE-2012
Project: WildFly Core
Issue Type: Bug
Components: Logging
Affects Versions: 3.0.0.Alpha13
Reporter: ted won
Assignee: ted won
Priority: Minor
In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter.
And the COLOR-PATTERN named-formatter is defined with {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n".{noformat}
It is working as it is defined with colors.
{code:title=standalone.xml}
...
<subsystem xmlns="urn:jboss:domain:logging:3.0">
<console-handler name="CONSOLE">
<level name="INFO"/>
<formatter>
<named-formatter name="COLOR-PATTERN"/>
</formatter>
</console-handler>
...
<formatter name="COLOR-PATTERN">
<pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
</formatter>
</subsystem>
...
{code}
However there is a inconsistency in the CLI and WildFly admin console views.
{noformat}
In the CLI, CONSOLE formatter is "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n". It is different with the working logging format.
{noformat}
{code:title=JBoss CLI}
[standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
{
"outcome" => "success",
"result" => {
"autoflush" => true,
"enabled" => true,
"encoding" => undefined,
"filter" => undefined,
"filter-spec" => undefined,
"formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n",
"level" => "INFO",
"name" => "CONSOLE",
"named-formatter" => "COLOR-PATTERN",
"target" => "System.out"
}
}
{code}
It is possible to reproduce with all profiles and all modes.
* standalone.xml
* standalone-full-ha.xml
* standalone mode
* domain mode
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months
[JBoss JIRA] (WFCORE-2011) Inconsistency of formatter and named-formatter in console logging handler
by ted won (JIRA)
ted won created WFCORE-2011:
-------------------------------
Summary: Inconsistency of formatter and named-formatter in console logging handler
Key: WFCORE-2011
URL: https://issues.jboss.org/browse/WFCORE-2011
Project: WildFly Core
Issue Type: Bug
Components: Logging
Affects Versions: 3.0.0.Alpha13
Reporter: ted won
Assignee: ted won
Priority: Minor
Attachments: COLOR-PATTERN.png, CONSOLE-console-handler.png
In logging subsystem the default CONSOLE console-handler is defined with COLOR-PATTERN named-formatter.
And the COLOR-PATTERN named-formatter is defined with {noformat}"%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n".{noformat}
It is working as it is defined with colors.
{code:title=standalone.xml}
...
<subsystem xmlns="urn:jboss:domain:logging:3.0">
<console-handler name="CONSOLE">
<level name="INFO"/>
<formatter>
<named-formatter name="COLOR-PATTERN"/>
</formatter>
</console-handler>
...
<formatter name="COLOR-PATTERN">
<pattern-formatter pattern="%K{level}%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n"/>
</formatter>
</subsystem>
...
{code}
However there is a inconsistency in the CLI and WildFly admin console views.
{noformat}
In the CLI, CONSOLE formatter is "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n". It is different with the working logging format.
{noformat}
{code:title=JBoss CLI}
[standalone@localhost:9990 /] /subsystem=logging/console-handler=CONSOLE:read-resource
{
"outcome" => "success",
"result" => {
"autoflush" => true,
"enabled" => true,
"encoding" => undefined,
"filter" => undefined,
"filter-spec" => undefined,
"formatter" => "%d{HH:mm:ss,SSS} %-5p [%c] (%t) %s%e%n",
"level" => "INFO",
"name" => "CONSOLE",
"named-formatter" => "COLOR-PATTERN",
"target" => "System.out"
}
}
{code}
It is possible to reproduce with all profiles and all modes.
* standalone.xml
* standalone-full-ha.xml
* standalone mode
* domain mode
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years, 7 months