[jboss-jira] [JBoss JIRA] (WFLY-10861) MP Health - security enabled, no user yed added, user get info about adding user to access management interface, HTTP code is 200, should be 500
Rostislav Svoboda (JIRA)
issues at jboss.org
Fri Aug 24 03:54:00 EDT 2018
[ https://issues.jboss.org/browse/WFLY-10861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13623637#comment-13623637 ]
Rostislav Svoboda edited comment on WFLY-10861 at 8/24/18 3:53 AM:
-------------------------------------------------------------------
*Web console* - I looked at http://localhost:9990/console and I didn't get redirected to the "help" page http://localhost:9990/error/index.html so I would be notified about adding user.
But I knew what I have to do :) So I added user via {{bin/add-user.sh -s -u admin -p admin.password}}.
Bu to my surprise the password wasn't working when accessing http://localhost:9990/console
The only way is to restart the server. This is mess, PicketBox can handle this case, no need for restarts.
So it's apparent that Elytron is caching the content of mgmt-users.properties. So I went ahead and removed previously defined user and tried {{curl -v --digest -u admin:admin.password http://localhost:9990/health}}
I received valid HTTP/1.1 200 OK response instead of HTTP/1.1 401 Unauthorized.
So server restart/reload is needed when Elytron is used.
Another observation for PicketBox vs. Elytron is that Elytron is really verbose and *curl output* is much longer
PicketBox case:
{code}
curl -v --digest -u admin:admin.password http://localhost:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9990 (#0)
* Server auth using Digest with user 'admin'
> GET /health HTTP/1.1
> Host: localhost:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Type: application/json
< Content-Length: 28
< Date: Fri, 24 Aug 2018 07:47:49 GMT
<
* Connection #0 to host localhost left intact
{"outcome":"UP","checks":[]}
{code}
Elytron case:
{code}
curl -v --digest -u admin:admin.password http://localhost:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9990 (#0)
* Server auth using Digest with user 'admin'
> GET /health HTTP/1.1
> Host: localhost:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Connection: keep-alive
< WWW-Authenticate: Digest realm="ManagementRealm", nonce="AAAAAQAAf0XcSniUDNEXtFMgcKlU5y/vgWnDOsCf5tVMn4HVemjLJnxHJSA=", opaque="00000000000000000000000000000000", algorithm=MD5, qop=auth
< Content-Length: 77
< Content-Type: text/html
< Date: Fri, 24 Aug 2018 07:46:32 GMT
<
* Ignoring the response-body
* Connection #0 to host localhost left intact
* Issue another request to this URL: 'http://localhost:9990/health'
* Found bundle for host localhost: 0x7fa212806370 [can pipeline]
* Re-using existing connection! (#0) with host localhost
* Connected to localhost (127.0.0.1) port 9990 (#0)
* Server auth using Digest with user 'admin'
> GET /health HTTP/1.1
> Host: localhost:9990
> Authorization: Digest username="admin", realm="ManagementRealm", nonce="AAAAAQAAf0XcSniUDNEXtFMgcKlU5y/vgWnDOsCf5tVMn4HVemjLJnxHJSA=", uri="/health", cnonce="NzZlYTJmNTk3YjQwNTIwOTBkZTQ1MWY2MWVhNWU0ZjY=", nc=00000001, qop=auth, response="f00379076346017ab8d81291d82bcb1e", opaque="00000000000000000000000000000000", algorithm="MD5"
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Type: application/json
< Content-Length: 28
< Date: Fri, 24 Aug 2018 07:46:32 GMT
<
* Connection #0 to host localhost left intact
{"outcome":"UP","checks":[]}
{code}
was (Author: rsvoboda):
I looked now at http://localhost:9990/console and I didn't get redirected to the "help" page http://localhost:9990/error/index.html so I would be notified about adding user.
But I knew what I have to do :) So I added user via {{bin/add-user.sh -s -u admin -p admin.password}}.
Bu to my surprise the password wasn't working when accessing http://localhost:9990/console
The only way is to restart the server. This is mess, PicketBox can handle this case, no need for restarts.
So it's apparent that Elytron is caching the content of mgmt-users.properties. So I went ahead and removed previously defined user and tried {{curl -v --digest -u admin:admin.password http://localhost:9990/health}}
I received valid HTTP/1.1 200 OK response instead of HTTP/1.1 401 Unauthorized.
So server restart/reload is needed when Elytron is used.
Another observation for PicketBox vs. Elytron is that Elytron is really verbose and curl output is long
PicketBox case:
{code}
curl -v --digest -u admin:admin.password http://localhost:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9990 (#0)
* Server auth using Digest with user 'admin'
> GET /health HTTP/1.1
> Host: localhost:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Type: application/json
< Content-Length: 28
< Date: Fri, 24 Aug 2018 07:47:49 GMT
<
* Connection #0 to host localhost left intact
{"outcome":"UP","checks":[]}
{code}
Elytron case:
{code}
curl -v --digest -u admin:admin.password http://localhost:9990/health
* Trying 127.0.0.1...
* TCP_NODELAY set
* Connected to localhost (127.0.0.1) port 9990 (#0)
* Server auth using Digest with user 'admin'
> GET /health HTTP/1.1
> Host: localhost:9990
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 401 Unauthorized
< Connection: keep-alive
< WWW-Authenticate: Digest realm="ManagementRealm", nonce="AAAAAQAAf0XcSniUDNEXtFMgcKlU5y/vgWnDOsCf5tVMn4HVemjLJnxHJSA=", opaque="00000000000000000000000000000000", algorithm=MD5, qop=auth
< Content-Length: 77
< Content-Type: text/html
< Date: Fri, 24 Aug 2018 07:46:32 GMT
<
* Ignoring the response-body
* Connection #0 to host localhost left intact
* Issue another request to this URL: 'http://localhost:9990/health'
* Found bundle for host localhost: 0x7fa212806370 [can pipeline]
* Re-using existing connection! (#0) with host localhost
* Connected to localhost (127.0.0.1) port 9990 (#0)
* Server auth using Digest with user 'admin'
> GET /health HTTP/1.1
> Host: localhost:9990
> Authorization: Digest username="admin", realm="ManagementRealm", nonce="AAAAAQAAf0XcSniUDNEXtFMgcKlU5y/vgWnDOsCf5tVMn4HVemjLJnxHJSA=", uri="/health", cnonce="NzZlYTJmNTk3YjQwNTIwOTBkZTQ1MWY2MWVhNWU0ZjY=", nc=00000001, qop=auth, response="f00379076346017ab8d81291d82bcb1e", opaque="00000000000000000000000000000000", algorithm="MD5"
> User-Agent: curl/7.54.0
> Accept: */*
>
< HTTP/1.1 200 OK
< Connection: keep-alive
< Content-Type: application/json
< Content-Length: 28
< Date: Fri, 24 Aug 2018 07:46:32 GMT
<
* Connection #0 to host localhost left intact
{"outcome":"UP","checks":[]}
{code}
> MP Health - security enabled, no user yed added, user get info about adding user to access management interface, HTTP code is 200, should be 500
> ------------------------------------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10861
> URL: https://issues.jboss.org/browse/WFLY-10861
> Project: WildFly
> Issue Type: Bug
> Components: Management, MP Health
> Reporter: Rostislav Svoboda
> Assignee: Kabir Khan
> Priority: Blocker
> Fix For: 14.0.0.CR1
>
>
> I do {{:write-attribute(name=security-enabled, value=true)}} ++ reload of the server
> Note: I didn't add user via {{bin/add-user.sh}}
> ----
> Kabir edit: the full command is:
> /subsystem=microprofile-health-smallrye:write-attribute(name=security-enabled,value=true)
> ----
> When I'm trying to access http://127.0.0.1:9990/health I receive page which is there primarily for web console:
> {code}
> <h3>Your WildFly Application Server is running.</h3>
> <p>However you have <strong>not</strong> yet <strong>added any users</strong> to be able
> to access the admin console.</p>
> <p>To add a new user execute the <code>add-user.sh</code> script within the bin folder of
> your WildFly installation and enter the requested information.</p>
> {code}
> Can /health endpoint get customized response in case no mgmt user is defined on server side ?
> Current response can be little confusing if user is not yet so familiar with WildFly.
> -I marked this as minor bug.- ... see comments
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
More information about the jboss-jira
mailing list