[JBoss JIRA] (WFLY-9561) HttpServletRequest.login(username, password) not creating HttpSession if it doesn't already exist. (Elytron)
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-9561?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-9561:
-------------------------------
Fix Version/s: 12.0.0.Final
(was: 12.0.0.CR1)
> HttpServletRequest.login(username, password) not creating HttpSession if it doesn't already exist. (Elytron)
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-9561
> URL: https://issues.jboss.org/browse/WFLY-9561
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web (Undertow)
> Affects Versions: 11.0.0.Final
> Reporter: Stanislav Grushevskiy
> Assignee: Darran Lofthouse
> Fix For: 12.0.0.Final
>
> Attachments: test.zip
>
>
> If Elytron security domain (in WildFly 11, default "standalone.xml") is used for programmatic login, cookie "JSESSIONID" is not set in response. So following requests are sent without "JSESSIONID".
> @Path("login")
> public class LoginService {
> @Context
> private HttpServletRequest request;
> @POST
> public void login(LoginForm form) throws ServletException {
> request.login(form.getLogin(), form.getPassword());
> }
> }
> <?xml version="1.0" encoding="UTF-8"?>
> <jboss-web>
> <security-domain>application-security-domain</security-domain>
> </jboss-web>
> If I add manual interaction with Session in login method, "JSESSIONID" is set.
> OR
> If I delete "jboss-web.xml" and default old "ApplicationRealm" is used, "JSESSIONID" is set.
> "JSESSIONID" is set in WildFly 10.0.0.Final and in 10.1.0.Final, because there is no Elytron there and "ApplicationRealm" is used.
> Test project is attached, create application user (add-user.sh) with username "wildfly" and password "wildfly".
> Run "mvn wildfly:deploy".
> Go to http://localhost:8080/test/test.html and press "Login" button and then "Check Auth".
> In this project you can uncomment code below (// uncomment the row below to get it working with elytron) to add session interaction or comment code below (<!-- comment the row below to use default ApplicationRealm from old security system, not elytron -->) to use old "ApplicationRealm".
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9489) Remove need for application-security-domain mapping
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-9489?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-9489:
-------------------------------
Fix Version/s: 12.0.0.Final
(was: 12.0.0.CR1)
> Remove need for application-security-domain mapping
> ---------------------------------------------------
>
> Key: WFLY-9489
> URL: https://issues.jboss.org/browse/WFLY-9489
> Project: WildFly
> Issue Type: Feature Request
> Components: Web (Undertow)
> Affects Versions: 11.0.0.Final
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Fix For: 12.0.0.Final
>
>
> The application-security-domain resource was added to map from the security domain specified within the deployment to a WildFly Elytron authentication factory with some additional related configuration.
> It should be possible to define all of this within a deployment descriptor.
> Additionally the subsystem includes a default-security-domain attribute, it should likely contain some default Elytron configuration options.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9417) No default-response-code during deployment sent
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-9417?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-9417:
-------------------------------
Fix Version/s: 12.0.0.Final
(was: 12.0.0.CR1)
> No default-response-code during deployment sent
> -----------------------------------------------
>
> Key: WFLY-9417
> URL: https://issues.jboss.org/browse/WFLY-9417
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 11.0.0.CR1
> Reporter: Nero M
> Assignee: Stuart Douglas
> Fix For: 12.0.0.Final
>
> Original Estimate: 1 week
> Remaining Estimate: 1 week
>
> Hi, i am experiencing a strange behaviour with WF11 which was not like this on WF10.
> When a *.dodeploy file exists during server-start. The Default response code
> e.g.
> <host name="default-host" alias="localhost" default-response-code="503">
> Is not sent during the time of deployment. Instead any requests goes into a pending state with (seemingly) no timeout.
> If the *.dodeploy file is created AFTER the server boots up, the default response code is sent until the deployment is complete.
> (After this line): WFLYSRV0025: WildFly Full 11.0.0.CR1 (WildFly Core 3.0.4.Final) started in 6468ms
> I think the server should not "hang" during the deployment-time, just like it was on WF10.
> Is there anything which has to be changed in the standalone xml between 10 and 11 to get the same behaviour?
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9415) Add test cases to cover EJB client clustered session creation
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-9415?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-9415:
-------------------------------
Fix Version/s: 12.0.0.Final
(was: 12.0.0.CR1)
> Add test cases to cover EJB client clustered session creation
> -------------------------------------------------------------
>
> Key: WFLY-9415
> URL: https://issues.jboss.org/browse/WFLY-9415
> Project: WildFly
> Issue Type: Task
> Components: Clustering, Test Suite
> Affects Versions: 11.0.0.CR1
> Reporter: Richard Achmatowicz
> Assignee: Richard Achmatowicz
> Fix For: 12.0.0.Final
>
>
> EJB client session creation involves creating a proxy for a SFSB deployed on a remote server, which has the side effect of creating a session instance on the chosen target node.
> Whether or not the operation is successful depends on three factors:
> * the connections defined in the EJB client configuration
> * the server environment in which the client is executing
> * any strong affinity set by the client
> These tests consider session creation in a clustered environment. The default server environment is a cluster called "ejb" with two nodes, "node-0" and "node-1".
> The following test scenarios are covered:
> 1. "normal" scenario
> * client configuration: points to node-0
> * server environment: module deployed on cluster "ejb" = {node-0, node-1}
> 2. "failover" scenario
> * client configuration: points to node-0
> * server environment: module deployed on cluster "ejb" = {node-1}
> 3. "bad connection" scenario
> * client configuration: points to node-2 (non-existent)
> * server environment: module deployed on cluster "ejb" = {node-0, node-1}
> As mentioned earlier, these tests operate in a single two-node cluster environment. A third singleton, non-clustered node added to the available environment would permit more complex scenarios (where we could test cluster affinity specification more directly).
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months
[JBoss JIRA] (WFLY-9702) SSO Integration for Programmatic Authentication
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-9702?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-9702:
-------------------------------
Fix Version/s: 12.0.0.Final
(was: 12.0.0.CR1)
> SSO Integration for Programmatic Authentication
> -----------------------------------------------
>
> Key: WFLY-9702
> URL: https://issues.jboss.org/browse/WFLY-9702
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Security, Web (Undertow)
> Reporter: Darran Lofthouse
> Assignee: Darran Lofthouse
> Priority: Critical
> Fix For: 12.0.0.Final
>
>
> At the moment the SSO integration only fully covers authentication mechanisms as they can be wrapped, we need to revisit for programmatic authentication.
> In this scenario we don't have either a wrapped mechanism or a CallbackHandler.
> Couple of options: -
> * Can we get away with pushing in some form of IdentityCache factory the mechs can obtain from the request? This may miss the additional notifications the SSO impl depends on.
> * Can we also better support listening for the notifications without the need for wrappers? This could cover both mechs and programmatic authentication?
> * Instead do we make the programmatic authenticator pluggable, i.e. push in an SSO aware impl, it can choose how to handle it's own caching and also doesn't need the notifications as it is in control of that stage of the process.
> *
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 2 months