That new implementation apparently got botched by the text editor I used,
so here it is inline for the sake of readability:
private void configure() {
//prevent the server and it's version from being transmitted
HttpConfiguration httpConfiguration = new HttpConfiguration();
httpConfiguration.setSendServerVersion(false);
HttpConnectionFactory factory = new
HttpConnectionFactory(httpConfiguration);
ServerConnector connector = new ServerConnector(this.server,
factory);
connector.setPort(this.port);
ConstraintSecurityHandler constraintSecurityHandler = new
ConstraintSecurityHandler();
Constraint constraint = new Constraint();
constraint.setAuthenticate(true);
constraint.setRoles(new String[]{"user"});
constraintSecurityHandler.setAuthenticator(new
FormAuthenticator("/login", "/error", false));
ConstraintMapping constraintMapping = new ConstraintMapping();
constraintMapping.setPathSpec("/*");
constraintMapping.setConstraint(constraint);
LoginService loginService = *createHashLoginService*(“placeholder”);
this.server.addBean(loginService);
this.server.setSessionIdManager(new
DefaultSessionIdManager(this.server));
SessionHandler sessionHandler = new SessionHandler();
sessionHandler.setUsingCookies(true);
sessionHandler.setSessionIdPathParameterName("none"); // Prevent
JSESSIONID in URL.
constraintSecurityHandler.setLoginService(loginService);
constraintSecurityHandler.addConstraintMapping(constraintMapping);
this.server.addConnector(connector);
ResourceHandler resourceHandler = new ResourceHandler();
resourceHandler.setDirectoriesListed(false);
resourceHandler.setWelcomeFiles(new String[]{"index.html"});
resourceHandler.setResourceBase("web/");
ServletContextHandler servletContextHandler =
this.createServletContextHandlerAndRegisterServlets(true);
constraintSecurityHandler.setHandler(resourceHandler);
HandlerList handlers = new HandlerList();
handlers.setHandlers(new Handler[]{
sessionHandler,
constraintSecurityHandler,
servletContextHandler});
this.server.setHandler(handlers);
try {
this.server.start();
this.server.dump(System.*out*);
}
catch (Throwable throwable) {
*LOGGER*.error("Error starting web server: " +
throwable.getMessage(), throwable);
}
}
private static LoginService createHashLoginService(String realm) {
HashLoginService hashLoginService = new HashLoginService();
hashLoginService.setConfig("conf/realm");
hashLoginService.setHotReload(true);
hashLoginService.setName(realm);
return hashLoginService;
}
*Chelsey Morgeson*
Software Engineer
*M* +1 859 582 5335
[email protected]
<http://www.lexmark.com/>
www.lexmark.com
On Tue, May 2, 2017 at 1:37 PM, Chelsey Morgeson <[email protected]>
wrote:
> I've attached the initialization code for both the old and new versions
> for comparison sake. I pulled out a few pieces that were specific to the
> product but not related to the initialization so everything relevant should
> be included.
>
> *Chelsey Morgeson*
> Software Engineer
>
> *M* +1 859 582 5335 <(859)%20582-5335>
> [email protected]
>
> <http://www.lexmark.com/>
> www.lexmark.com
>
> On Tue, May 2, 2017 at 1:15 PM, Joakim Erdfelt <[email protected]> wrote:
>
>> What does your session initialization code look like?
>>
>>
>>
>> Joakim Erdfelt / [email protected]
>>
>> On Tue, May 2, 2017 at 9:00 AM, Chelsey Morgeson <[email protected]>
>> wrote:
>>
>>> Hello all,
>>>
>>> My team is responsible for developing network monitoring software that
>>> uses Jetty for our user interface. We have recently upgraded from
>>> Jetty 9.3.0.v20150612 to 9.4.2.v20170220, which of course had major changes
>>> in the session management. The only required changes that we saw necessary
>>> were replacing the old HashSessionIdManager with the new
>>> DefaultSessionIdManager, and removing the old HashSessionManager since it
>>> no longer exists. We are also using a HashLoginService for authentication.
>>>
>>> Unfortunately, after this upgrade our authentication mechanism no longer
>>> works. The login screen appears correctly when the realm file is present,
>>> and debugging the process shows that inputting the correct username and
>>> password does return a 303 as expected from the authentication endpoint,
>>> but once Jetty redirects to our user interface's homepage, the user is once
>>> again redirected to the login screen because the homepage returned a 303 as
>>> well. No error is encountered and the JSESSIONID cookie is stored as if
>>> things were working as expected, so I am hoping someone more familiar with
>>> the product may have some insight as to what could cause this. Again,
>>> everything worked fine before the Jetty upgrade.
>>>
>>> Thanks in advance,
>>> Chelsey
>>>
>>> _______________________________________________
>>> jetty-users mailing list
>>> [email protected]
>>> To change your delivery options, retrieve your password, or unsubscribe
>>> from this list, visit
>>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>>>
>>
>>
>> _______________________________________________
>> jetty-users mailing list
>> [email protected]
>> To change your delivery options, retrieve your password, or unsubscribe
>> from this list, visit
>> https://dev.eclipse.org/mailman/listinfo/jetty-users
>>
>
>
_______________________________________________
jetty-users mailing list
[email protected]
To change your delivery options, retrieve your password, or unsubscribe from
this list, visit
https://dev.eclipse.org/mailman/listinfo/jetty-users
