[JBoss JIRA] (ELY-1032) Help output has limit for line length 160 chars and it leads to ugly line break in the middle of one option.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1032?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse reassigned ELY-1032:
-------------------------------------
Assignee: Peter Skopek (was: Darran Lofthouse)
> Help output has limit for line length 160 chars and it leads to ugly line break in the middle of one option.
> ------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1032
> URL: https://issues.jboss.org/browse/ELY-1032
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
> Fix For: 1.1.0.Beta34
>
>
> Help output has limit 160 chars for line length and it leads to ugly line break in the middle of one option.
> Command
> {code}
> java -jar wildfly-elytron-tool.jar credential-store --help
> {code}
> has this output:
> {code}
> usage: java -jar wildfly-elytron-tool.jar credential-store -a <alias> | -e <alias> | -h | -r <alias> | -v [-c] [-f] [-i <arg>] [-l <loc>] [-p <pwd>] [-s
> <arg>] [-t <type>] [-u <uri>] [-x <secret to store>]
> {code}
> I expect at least line break before "-s" option
> {code}
> usage: java -jar wildfly-elytron-tool.jar credential-store -a <alias> | -e <alias> | -h | -r <alias> | -v [-c] [-f] [-i <arg>] [-l <loc>] [-p <pwd>]
> [-s <arg>] [-t <type>] [-u <uri>] [-x <secret to store>]
> {code}
> The best option would be some dynamic settings of line length
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1032) Help output has limit for line length 160 chars and it leads to ugly line break in the middle of one option.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-1032?page=com.atlassian.jira.plugin.s... ]
Darran Lofthouse updated ELY-1032:
----------------------------------
Fix Version/s: 1.1.0.Beta34
> Help output has limit for line length 160 chars and it leads to ugly line break in the middle of one option.
> ------------------------------------------------------------------------------------------------------------
>
> Key: ELY-1032
> URL: https://issues.jboss.org/browse/ELY-1032
> Project: WildFly Elytron
> Issue Type: Bug
> Reporter: Hynek Švábek
> Assignee: Peter Skopek
> Fix For: 1.1.0.Beta34
>
>
> Help output has limit 160 chars for line length and it leads to ugly line break in the middle of one option.
> Command
> {code}
> java -jar wildfly-elytron-tool.jar credential-store --help
> {code}
> has this output:
> {code}
> usage: java -jar wildfly-elytron-tool.jar credential-store -a <alias> | -e <alias> | -h | -r <alias> | -v [-c] [-f] [-i <arg>] [-l <loc>] [-p <pwd>] [-s
> <arg>] [-t <type>] [-u <uri>] [-x <secret to store>]
> {code}
> I expect at least line break before "-s" option
> {code}
> usage: java -jar wildfly-elytron-tool.jar credential-store -a <alias> | -e <alias> | -h | -r <alias> | -v [-c] [-f] [-i <arg>] [-l <loc>] [-p <pwd>]
> [-s <arg>] [-t <type>] [-u <uri>] [-x <secret to store>]
> {code}
> The best option would be some dynamic settings of line length
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (ELY-1014) Elytron auth method misconfiguration not logged
by Jan Kalina (JIRA)
[ https://issues.jboss.org/browse/ELY-1014?page=com.atlassian.jira.plugin.s... ]
Jan Kalina updated ELY-1014:
----------------------------
Git Pull Request: https://github.com/wildfly-security/wildfly-elytron/pull/746 (was: https://github.com/wildfly-security/wildfly-elytron/pull/732)
> Elytron auth method misconfiguration not logged
> -----------------------------------------------
>
> Key: ELY-1014
> URL: https://issues.jboss.org/browse/ELY-1014
> Project: WildFly Elytron
> Issue Type: Bug
> Components: Authentication Mechanisms
> Reporter: Martin Choma
> Assignee: Jan Kalina
> Priority: Blocker
> Labels: user_experience
>
> When deployment is configured to be secured with DIGEST, but {{http-authentication-factory}} does not list DIGEST mechanism, user is not informed about misconfiguration. Even when TRACE logging is turned on. When user tries to access app 403 http code is returned and Forbidden is shown in browser. I would expect browser dialog to appear to allow user provide credentials (401 http status code).
> {code:title=web.xml}
> <login-config>
> <auth-method>DIGEST</auth-method>
> <realm-name>ApplicaitonRealm</realm-name>
> </login-config>
> {code}
> {code:title=standalone-elytron.xml}
> <http-authentication-factory name="application-http-authentication" http-server-mechanism-factory="global" security-domain="ApplicationDomain">
> <mechanism-configuration>
> <mechanism mechanism-name="BASIC">
> <mechanism-realm realm-name="Application Realm"/>
> </mechanism>
> <mechanism mechanism-name="FORM"/>
> </mechanism-configuration>
> </http-authentication-factory>
> {code}
> This applies globally to all authentication mechanisms, not only DIGEST.
> Could elytron handle misconfiguration:
> * either fail during deploying application as deployment requirement can't be satisfy
> * or provide reasonable elytron defaults of missing mechanism configuration.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (WFLY-8478) Setting elytron ssl-context on undertow without reload
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-8478?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-8478:
----------------------------------------
This is true, but we should be careful about simple advice to use {allow-resource-service-restart=true}. That's a power user setting that should only be used by people with a very clear understanding of the effects. It's not in any way a "better reload".
In this case {allow-resource-service-restart=true} is likely more useful, since I don't *think* bouncing the listener service will have widely cascading effects. But any advice to use {allow-resource-service-restart=true} should always include some comment on what the expected effects would be. The end user will very likely not have a clue and an uneducated guess will likely be too optimistic by far.
BTW, I'm not arguing with rejecting this issue if there is no reasonable way to update the service without a service restart. And I have reason to believe there is such a way. My point is just about what message we send to end users.
> Setting elytron ssl-context on undertow without reload
> ------------------------------------------------------
>
> Key: WFLY-8478
> URL: https://issues.jboss.org/browse/WFLY-8478
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Reporter: Martin Choma
> Assignee: Tomaz Cerar
> Labels: user_experience
>
> Please, allow setting of elytron ssl-context on undertow without reload.
> {code}
> [standalone@localhost:9990 /] /subsystem=undertow/server=default-server/https-listener=https:write-attribute(name=ssl-context,value=server)
> {
> "outcome" => "success",
> "response-headers" => {
> "operation-requires-reload" => true,
> "process-state" => "reload-required"
> }
> }
> {code}
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years
[JBoss JIRA] (HAWKULARQE-82) JMAN4 Feature Requests Test Cases Review
by Hayk Hovsepyan (JIRA)
Hayk Hovsepyan created HAWKULARQE-82:
----------------------------------------
Summary: JMAN4 Feature Requests Test Cases Review
Key: HAWKULARQE-82
URL: https://issues.jboss.org/browse/HAWKULARQE-82
Project: Hawkular QE
Issue Type: Task
Reporter: Hayk Hovsepyan
Assignee: Hayk Hovsepyan
Priority: Critical
Go through all JMAN4 Features and their QE tasks:
Make sure that all existing Polarion testcases are created and mentioned in QE tasks.
Review polarion testcases, make comments on QE tasks to fix testcases if necessary.
If testcases are missing, request to create them.
--
This message was sent by Atlassian JIRA
(v7.2.3#72005)
9 years