[JBoss JIRA] (WFLY-13397) MP HeaderPropagation does not propagate headers
by James Perkins (Jira)
[ https://issues.redhat.com/browse/WFLY-13397?page=com.atlassian.jira.plugi... ]
James Perkins updated WFLY-13397:
---------------------------------
Component/s: MP REST Client
> MP HeaderPropagation does not propagate headers
> -----------------------------------------------
>
> Key: WFLY-13397
> URL: https://issues.redhat.com/browse/WFLY-13397
> Project: WildFly
> Issue Type: Bug
> Components: MP REST Client
> Affects Versions: 19.0.0.Final
> Reporter: Thimo König
> Assignee: Brian Stansberry
> Priority: Major
> Attachments: mp-headerpropagation-1.0.0-SNAPSHOT-sources.jar, mp-headerpropagation-1.0.0-SNAPSHOT.war, openliberty_response.json, wildfly_response.json
>
>
> When calling a JAX-RS Resource from another JAX-RS Resource using the MP RestClient the propagation of headers does not work. I have created a sample app which is available on github https://github.com/koenigt/headerpropagation and attached [^mp-headerpropagation-1.0.0-SNAPSHOT.war] to this report aswell.
> Deploy the sample app and use CURL like:
> {code}
> curl -i -H "Accept: application/json" -H "Header2Propagate: PropagatedValue" http://localhost:8080/mp-hp/api/client {code}
> The expected result should be:
> {code:JSON}
> {
> "Name": "ClientResource",
> "org.eclipse.microprofile.rest.client.propagateHeaders": "Authorization,Accept-Language,Header2Propagate",
> "IncomingRequestHeaders": {
> "Accept": "[*/*]",
> "accept-encoding": "[gzip, deflate, br]",
> "Cache-Control": "[no-cache]",
> "connection": "[keep-alive]",
> "Content-Type": "[null]",
> "Header2Propagate": "[PropagatedValue]",
> "Host": "[localhost:9080]",
> "Postman-Token": "[8105e2ef-9b5f-4b3f-a7a9-cea73d51efee]",
> "User-Agent": "[PostmanRuntime/7.24.0]"
> },
> "ServerResponse": {
> "Name": "ServerResource",
> "IncomingRequestHeaders": {
> "Accept": "[application/json]",
> "Cache-Control": "[no-cache]",
> "connection": "[keep-alive]",
> "content-type": "[application/json]",
> "Header2Propagate": "[PropagatedValue]",
> "Host": "[localhost:9080]",
> "MyClientHeader": "[newHeaderValue]",
> "Pragma": "[no-cache]",
> "User-Agent": "[Apache-CXF/3.3.3-SNAPSHOT]"
> }
> }
> }
> {code}
> but since the header is not propagated you are getting only this:
> {code:JSON}
> {
> "Name": "ClientResource",
> "org.eclipse.microprofile.rest.client.propagateHeaders": "Authorization,Accept-Language,Header2Propagate",
> "IncomingRequestHeaders": {
> "Accept": "[*/*]",
> "Accept-Encoding": "[gzip, deflate, br]",
> "Cache-Control": "[no-cache]",
> "Connection": "[keep-alive]",
> "Header2Propagate": "[PropagatedValue]",
> "Host": "[localhost:8080]",
> "Postman-Token": "[6e36736f-3b55-4f34-9f39-063dbd4f4e8f]",
> "User-Agent": "[PostmanRuntime/7.24.0]"
> },
> "ServerResponse": {
> "Name": "ServerResource",
> "IncomingRequestHeaders": {
> "Accept": "[application/json]",
> "Connection": "[Keep-Alive]",
> "Host": "[localhost:8080]",
> "User-Agent": "[Apache-HttpClient/4.5.11 (Java/12)]",
> "uber-trace-id": "[a0d9d0ac4c54614%3Ac82190f35d41f958%3Aa0d9d0ac4c54614%3A1]"
> }
> }
> }
> {code}
> This issue has already been discussed on https://groups.google.com/forum/#!topic/wildfly/QOx3AfrXAMc and Rebecca Searls (rseals(a)redhat.com) ask me to file this bug report
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (ELY-1954) Submission for "j_security_check" login does not work if URL has no trailing slash
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/ELY-1954?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse moved WFLY-13379 to ELY-1954:
----------------------------------------------
Project: WildFly Elytron (was: WildFly)
Key: ELY-1954 (was: WFLY-13379)
Component/s: HTTP
(was: Security)
Affects Version/s: (was: 19.0.0.Final)
> Submission for "j_security_check" login does not work if URL has no trailing slash
> ----------------------------------------------------------------------------------
>
> Key: ELY-1954
> URL: https://issues.redhat.com/browse/ELY-1954
> Project: WildFly Elytron
> Issue Type: Bug
> Components: HTTP
> Reporter: Wolfgang Knauf
> Assignee: Darran Lofthouse
> Priority: Major
> Attachments: Security.ear, configure.cli, restore-configuration.cli
>
>
> Attached file "Security.ear" contains a web application with a single jsp page "index.jsp" and form based login, which is secured by a Database Identity Store (Elytron).
> When calling the root URL of the webapp without specifiying any page and {color:red}*no*{color} trailing slash (http://localhost:8080/SecurityWeb), on WildFly 11 the login form is shown, and then the welcome file "index.jsp" is shown.
> On WildFly 19, the login form is shown, and after successful login, there is an error message "404 - Not Found", and the URL in the adress bar changes to http://localhost:8080/j_security_check
> It works if the URL is "http://localhost:8080/SecurityWeb/" (trailing slash). It seems WildFly 11 appends the "/" automatically when redirecting to the login form, while WildFly 19 keeps this URL.
> To run the sample, you have to add the Elytron config - the script "configure.cli" can be used for this:
> jboss-cli.bat --file=path_to\configure.cli
> The script "restore-configuration.cli" undoes this configuration.
> Username/Password are e.g. "admin"/"admin" - the sample creates a user table based on an ejb and "import.sql" inserts users.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13379) Submission for "j_security_check" login does not work if URL has no trailing slash
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13379?page=com.atlassian.jira.plugi... ]
Darran Lofthouse updated WFLY-13379:
------------------------------------
Summary: Submission for "j_security_check" login does not work if URL has no trailing slash (was: Redirect after "j_security_check" login does not work if URL has no trailing slash)
> Submission for "j_security_check" login does not work if URL has no trailing slash
> ----------------------------------------------------------------------------------
>
> Key: WFLY-13379
> URL: https://issues.redhat.com/browse/WFLY-13379
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 19.0.0.Final
> Reporter: Wolfgang Knauf
> Assignee: Darran Lofthouse
> Priority: Major
> Attachments: Security.ear, configure.cli, restore-configuration.cli
>
>
> Attached file "Security.ear" contains a web application with a single jsp page "index.jsp" and form based login, which is secured by a Database Identity Store (Elytron).
> When calling the root URL of the webapp without specifiying any page and {color:red}*no*{color} trailing slash (http://localhost:8080/SecurityWeb), on WildFly 11 the login form is shown, and then the welcome file "index.jsp" is shown.
> On WildFly 19, the login form is shown, and after successful login, there is an error message "404 - Not Found", and the URL in the adress bar changes to http://localhost:8080/j_security_check
> It works if the URL is "http://localhost:8080/SecurityWeb/" (trailing slash). It seems WildFly 11 appends the "/" automatically when redirecting to the login form, while WildFly 19 keeps this URL.
> To run the sample, you have to add the Elytron config - the script "configure.cli" can be used for this:
> jboss-cli.bat --file=path_to\configure.cli
> The script "restore-configuration.cli" undoes this configuration.
> Username/Password are e.g. "admin"/"admin" - the sample creates a user table based on an ejb and "import.sql" inserts users.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13379) Redirect after "j_security_check" login does not work if URL has no trailing slash
by Darran Lofthouse (Jira)
[ https://issues.redhat.com/browse/WFLY-13379?page=com.atlassian.jira.plugi... ]
Darran Lofthouse commented on WFLY-13379:
-----------------------------------------
Just to confirm I have also recreated this locally on the latest commit in WildFly master 90ebbec1e5883d5ebfe9f4a82a3961a2455ced4f - I am having a look now at what is needed.
Fundamentally the issue is actually in relation to the lack of a redirect, in the scenario described no redirect occurs. On attempting to access a secured resource we return the login page as the immediate response, the problem is that is the immediate response returned was the root of the web application whilst missing the trailing slash that is the only URL the browser is aware of so a FORM with the following action will submit to the root context.
{code:html}
<form action="j_security_check" method="POST">
{code}
> Redirect after "j_security_check" login does not work if URL has no trailing slash
> ----------------------------------------------------------------------------------
>
> Key: WFLY-13379
> URL: https://issues.redhat.com/browse/WFLY-13379
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 19.0.0.Final
> Reporter: Wolfgang Knauf
> Assignee: Darran Lofthouse
> Priority: Major
> Attachments: Security.ear, configure.cli, restore-configuration.cli
>
>
> Attached file "Security.ear" contains a web application with a single jsp page "index.jsp" and form based login, which is secured by a Database Identity Store (Elytron).
> When calling the root URL of the webapp without specifiying any page and {color:red}*no*{color} trailing slash (http://localhost:8080/SecurityWeb), on WildFly 11 the login form is shown, and then the welcome file "index.jsp" is shown.
> On WildFly 19, the login form is shown, and after successful login, there is an error message "404 - Not Found", and the URL in the adress bar changes to http://localhost:8080/j_security_check
> It works if the URL is "http://localhost:8080/SecurityWeb/" (trailing slash). It seems WildFly 11 appends the "/" automatically when redirecting to the login form, while WildFly 19 keeps this URL.
> To run the sample, you have to add the Elytron config - the script "configure.cli" can be used for this:
> jboss-cli.bat --file=path_to\configure.cli
> The script "restore-configuration.cli" undoes this configuration.
> Username/Password are e.g. "admin"/"admin" - the sample creates a user table based on an ejb and "import.sql" inserts users.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFWIP-311) OpenShift XP image doubled its size to 2GB compared to 7.3.0.GA 1GB
by Ken Wills (Jira)
[ https://issues.redhat.com/browse/WFWIP-311?page=com.atlassian.jira.plugin... ]
Ken Wills edited comment on WFWIP-311 at 4/23/20 9:24 AM:
----------------------------------------------------------
The size difference is likely not relevant yet. This dev preview build wasn't squashed as It was built on my laptop (multiple times) with 5 other images, and in order to push the images to the internal registry in a realistic timeframe, I wanted to get as much reuse from layer caching as I could.
When we do an OSBS build, OSBS will squash by default, and this will likely not be an issue.
was (Author: luck3y):
The size difference is likely not relevant yet. This dev preview build wasn't squashed as It was built on my laptop with 5 other images, and in order to push the images to the internal registry in a realistic timeframe, I wanted to get as much reuse from layer caching as I could.
When we do an OSBS build, OSBS will squash by default, and this will likely not be an issue.
> OpenShift XP image doubled its size to 2GB compared to 7.3.0.GA 1GB
> -------------------------------------------------------------------
>
> Key: WFWIP-311
> URL: https://issues.redhat.com/browse/WFWIP-311
> Project: WildFly WIP
> Issue Type: Bug
> Components: OpenShift
> Reporter: Martin Choma
> Assignee: Jeff Mesnil
> Priority: Major
> Attachments: Screenshot from 2020-04-23 06-56-37.png
>
>
> I have started to play with OpenShift XP image {{docker-registry.upshift.redhat.com/kwills/eap-xp1-openjdk8-openshift-rhel7:EAP7-1484}} and I have noticed it is nearly 2GB big. Used to be 0.92 GB for 7.3.0.GA or CD19.
> Also strange is there is much more layers compared to several layers in previous releases
> From dive output it seems every bash command result in own layer. Dive is reporting 624MB of waste space.
> !Screenshot from 2020-04-23 06-56-37.png|thumbnail!
> I am setting priority just to major because it is not official image yet. But if this will be the case of official image as well, I will raise priority. In OCP 4 there is no image/layer cache so image must be "downloaded" for each build from registry into pod.
> [1]
> {code}
> docker-registry.upshift.redhat.com/kwills/eap-xp1-openjdk8-openshift-rhel... 1.93 GB
> registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-7-eap73-openjdk11... 920 MB
> registry-proxy.engineering.redhat.com/rh-osbs/jboss-eap-7-tech-preview-ea... 921 MB
> {code}
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFLY-13403) Upgrade Hibernate ORM from 5.3.16 to 5.3.17
by Ilia Vassilev (Jira)
[ https://issues.redhat.com/browse/WFLY-13403?page=com.atlassian.jira.plugi... ]
Ilia Vassilev moved JBEAP-19332 to WFLY-13403:
----------------------------------------------
Project: WildFly (was: JBoss Enterprise Application Platform)
Key: WFLY-13403 (was: JBEAP-19332)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Build System
JPA / Hibernate
(was: Hibernate)
Fix Version/s: (was: 7.3.2.GA)
> Upgrade Hibernate ORM from 5.3.16 to 5.3.17
> -------------------------------------------
>
> Key: WFLY-13403
> URL: https://issues.redhat.com/browse/WFLY-13403
> Project: WildFly
> Issue Type: Component Upgrade
> Components: Build System, JPA / Hibernate
> Reporter: Ilia Vassilev
> Assignee: Ilia Vassilev
> Priority: Major
> Labels: downstream_dependency
>
> This is intended for EAP 7.3.2.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years
[JBoss JIRA] (WFCORE-4895) Bootable jar runtime module
by Jeff Mesnil (Jira)
[ https://issues.redhat.com/browse/WFCORE-4895?page=com.atlassian.jira.plug... ]
Jeff Mesnil updated WFCORE-4895:
--------------------------------
Issue Type: Enhancement (was: Feature Request)
> Bootable jar runtime module
> ---------------------------
>
> Key: WFCORE-4895
> URL: https://issues.redhat.com/browse/WFCORE-4895
> Project: WildFly Core
> Issue Type: Enhancement
> Components: Build System
> Reporter: Jean Francois Denise
> Assignee: Jean Francois Denise
> Priority: Major
>
> bootable jar runtime module is not a new feature per se, it is an enabler for Wildfly bootable jar feature.
> We propose to add a new "bootable-jar" maven parent module with 2 new sub modules: org.wildfly.core:wildfly-jar-boot and org.wildfly.core:wildfly-jar-runtime.
> wildfly-jar-boot artifact would be shaded inside the bootable jar (done by tooling),
> wildfly-jar-runtime artifact is executed from the modular classloader and starts the actual server.
> To run tests against a bootable jar, ts.bootable profile is added.
--
This message was sent by Atlassian Jira
(v7.13.8#713008)
6 years