[JBoss JIRA] (WFLY-6784) Add possibility to enable websocket compression via management model
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-6784?page=com.atlassian.jira.plugin.... ]
Ingo Weiss reassigned WFLY-6784:
--------------------------------
Assignee: Ingo Weiss (was: Stuart Douglas)
> Add possibility to enable websocket compression via management model
> --------------------------------------------------------------------
>
> Key: WFLY-6784
> URL: https://issues.jboss.org/browse/WFLY-6784
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Radim Hatlapatka
> Assignee: Ingo Weiss
> Priority: Critical
>
> In EAP 6 the websockets compression was enabled by default allowing to use pre-deflate compression when requested by client.
> There is support for it in Undertow but there is no option to enable it in WildFly 10. This option should be added to WildFly and should probably set by default to true as that would be consistent with default behaviour when using WebSockets with EAP 6.4.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-6784) Add possibility to enable websocket compression via management model
by Ingo Weiss (JIRA)
[ https://issues.jboss.org/browse/WFLY-6784?page=com.atlassian.jira.plugin.... ]
Ingo Weiss updated WFLY-6784:
-----------------------------
Original Estimate: 2 days
Remaining Estimate: 2 days
> Add possibility to enable websocket compression via management model
> --------------------------------------------------------------------
>
> Key: WFLY-6784
> URL: https://issues.jboss.org/browse/WFLY-6784
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 10.0.0.Final
> Reporter: Radim Hatlapatka
> Assignee: Ingo Weiss
> Priority: Critical
> Original Estimate: 2 days
> Remaining Estimate: 2 days
>
> In EAP 6 the websockets compression was enabled by default allowing to use pre-deflate compression when requested by client.
> There is support for it in Undertow but there is no option to enable it in WildFly 10. This option should be added to WildFly and should probably set by default to true as that would be consistent with default behaviour when using WebSockets with EAP 6.4.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (ELY-19) OAuth Broker Security Realm
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/ELY-19?page=com.atlassian.jira.plugin.sys... ]
Darran Lofthouse commented on ELY-19:
-------------------------------------
Going to leave this unscheduled but open as I don't want it to completely drop off the radar - however yes now that we have capabilities and requirements this is going to be something to be provided by KeyCloak and not us - i.e. their subsystem has access to the internal APIs and the internal repository.
Maybe a good start will be to see about adding a security realm capability to the KeyCloak subsystem (or some related subsystem) that can at the very least perform evidence verification.
> OAuth Broker Security Realm
> ---------------------------
>
> Key: ELY-19
> URL: https://issues.jboss.org/browse/ELY-19
> Project: WildFly Elytron
> Issue Type: Sub-task
> Reporter: Darran Lofthouse
> Assignee: Pedro Igor
>
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1633) BoundedQueueThreadPoolResourceDefinition does not able to add additional check on the threads executor
by Lin Gao (JIRA)
Lin Gao created WFCORE-1633:
-------------------------------
Summary: BoundedQueueThreadPoolResourceDefinition does not able to add additional check on the threads executor
Key: WFCORE-1633
URL: https://issues.jboss.org/browse/WFCORE-1633
Project: WildFly Core
Issue Type: Bug
Reporter: Lin Gao
Assignee: Lin Gao
When there is already a long-running thread pool for a work manager and you try to create another one:
{{/subsystem=jca/workmanager=default/long-running-threads=custom:add(max-threads=30, queue-length=30)}}
you only get an opaque error message:
{{"failure-description" => "WFLYCTL0086: Failed to persist configuration change: WFLYCTL0084: Failed to marshal configuration",}} with a, also useless, {{java.lang.IllegalArgumentException}} in the server log.
It should be more obvious that the error is that you cannot create two long-running thread pools
To be able to check whether the {{long-running-threads/short-running-threads}} within one JCA workmanager is already defined when adding one, {{BoundedQueueThreadPoolResourceDefinition}} in {{threads}} subsystem needs to be extended to be able to check this.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (SECURITY-947) could not spécify version 3 for ldap connection
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-947?page=com.atlassian.jira.plug... ]
Darran Lofthouse reassigned SECURITY-947:
-----------------------------------------
Assignee: (was: Darran Lofthouse)
> could not spécify version 3 for ldap connection
> -----------------------------------------------
>
> Key: SECURITY-947
> URL: https://issues.jboss.org/browse/SECURITY-947
> Project: PicketBox
> Issue Type: Feature Request
> Components: JBossSX
> Reporter: cyril leclerc
>
> HI,
> in case of using LDAPExtLoginModule and ldap realm if in active directory there is more than 1000 groups it returns an error :
> Caused by: javax.naming.SizeLimitExceededException: [LDAP: error code 4 - Sizelimit Exceeded]; remaining name 'CN=Users,DC=realad,DC=ad'
> i can't change in AD the MAXPAGESIZE parameter and i can't specify the module to use version 3 of ldap how i can do ?
> it is a big issue for me -)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (SECURITY-947) could not spécify version 3 for ldap connection
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/SECURITY-947?page=com.atlassian.jira.plug... ]
Darran Lofthouse moved WFLY-6780 to SECURITY-947:
-------------------------------------------------
Project: PicketBox (was: WildFly)
Key: SECURITY-947 (was: WFLY-6780)
Workflow: classic default workflow (was: GIT Pull Request workflow )
Component/s: JBossSX
(was: Security)
> could not spécify version 3 for ldap connection
> -----------------------------------------------
>
> Key: SECURITY-947
> URL: https://issues.jboss.org/browse/SECURITY-947
> Project: PicketBox
> Issue Type: Feature Request
> Components: JBossSX
> Reporter: cyril leclerc
> Assignee: Darran Lofthouse
>
> HI,
> in case of using LDAPExtLoginModule and ldap realm if in active directory there is more than 1000 groups it returns an error :
> Caused by: javax.naming.SizeLimitExceededException: [LDAP: error code 4 - Sizelimit Exceeded]; remaining name 'CN=Users,DC=realad,DC=ad'
> i can't change in AD the MAXPAGESIZE parameter and i can't specify the module to use version 3 of ldap how i can do ?
> it is a big issue for me -)
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFLY-1598) Out of the box SSL - or shortly after.
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-1598?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse commented on WFLY-1598:
----------------------------------------
No WFLY-6745 is only a temporary solution in deprecated code.
> Out of the box SSL - or shortly after.
> --------------------------------------
>
> Key: WFLY-1598
> URL: https://issues.jboss.org/browse/WFLY-1598
> Project: WildFly
> Issue Type: Sub-task
> Components: Domain Management, Security
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Labels: management_security,, management_sso
> Fix For: 11.0.0.Alpha1
>
>
> There are various reasons that we do not support SSL/TLS out of the box e.g.
> - If we ship a default keystore then everyone has access to the private key.
> - Generating one on first boot we do not have sufficient information to generate it correctly, also the performance overhead.
> This issue is to explorer other options to encourage their use and make it easier to configure.
> As an example could the admin console detect a non encrypted connection and have an box that encourages the config along with a wizard like workflow to get it set up?
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months
[JBoss JIRA] (WFCORE-1632) Server processing request isn't stopped immediately but waits for request processing to finish
by Lin Gao (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1632?page=com.atlassian.jira.plugi... ]
Lin Gao moved JBEAP-5154 to WFCORE-1632:
----------------------------------------
Project: WildFly Core (was: JBoss Enterprise Application Platform)
Key: WFCORE-1632 (was: JBEAP-5154)
Workflow: GIT Pull Request workflow (was: CDW with loose statuses v1)
Component/s: Domain Management
IO
Server
(was: Domain Management)
(was: Server)
(was: Web (Undertow))
(was: IO)
Target Release: (was: 7.backlog.GA)
Affects Version/s: (was: 7.0.0.ER5)
(was: 7.0.0.CR2)
Release Notes Docs Status: (was: Documented as Known Issue)
> Server processing request isn't stopped immediately but waits for request processing to finish
> ----------------------------------------------------------------------------------------------
>
> Key: WFCORE-1632
> URL: https://issues.jboss.org/browse/WFCORE-1632
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management, IO, Server
> Reporter: Lin Gao
> Assignee: Lin Gao
> Priority: Critical
> Original Estimate: 1 day
> Remaining Estimate: 1 day
>
> When stopping server which is processing request, it terminates the connection from the client but doesn't stop the request processing as such.
> After debugging and searching when the issue appeared I've found out that the issue was introduced with this commit: [https://github.com/wildfly/wildfly-core/commit/7304c019705c5f7ec0378e1c51...]
> Steps to reproduce:
> 1) start EAP server with deployed app from attachment
> 2) create request to long running application: {{curl -i http://127.0.0.1:8080/long-running-servlet/HeavyProcessing?duration=25000}}
> 3) stop server (you can do it even gracefully) using {{./jboss-cli.sh -c ":shutdown(timeout=1)"}}
> See that server is stopped after 25 seconds since request from step 2 was issued, as that is duration of the request processing requested by param duration, instead of being terminated after 1 second.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
9 years, 6 months