Max Sessions on WebFlux

[marcusdacoregio]

• Add Documentation for Max Sessions on WebFlux #13791

[maradanasai]

HI @marcusdacoregio Thanks for this. Can you please take it forward?

[maradanasai]

Can't wait for this feature release in 6.2.0

[marcusdacoregio]

Hi, @maradanasai. Unfortunately, this will not make it into the 6.2 release. I will try to get it added for the first milestone of 6.3 though.

[jzheaux]

This looks great, @marcusdacoregio. Per your request, I've reviewed the following:

• Interface naming; I also took the liberty to comment on some class names
• DSL names and contracts

[jzheaux]

Having a Function as an API can be a bit more challenging. Have you considered having two methods:

.maxSessions(Function)

.maxSessions(Integer)

In this way, folks can supply a global max, should that be preferred, in a way that is clearly correct.

[jzheaux]

It's not clear to me how I'd state that for some authentications, there is no maximum. For example, is it:

.maxSessions((authentication) -> containsSomeAuthority(authentication) ? Mono.just(Integer.MAX_VALUE) : Mono.just(3))

or something else?

(I can see in the reference that it is -1, but this may be value to place in the JavaDoc, too. Also, since it is a magic number, you might consider a static constant like UNLIMITED. This adds clarity to the user's intent and it also gives you the ability to change that value in the future should it become necessary.)

[marcusdacoregio]

Instead of the user dealing with magic numbers, I think it would be better to define a SessionLimit POJO with a SessionLimit#of(int) and SessionLimit#unlimited() static factory methods to achieve a better declarative configuration.

In addition to that, there are now maximumSessions(SessionLimit) and maximumSessions(Function<Authentication, Mono<SessionLimit>) available.

.sessionManagement((sessionManagement) -> sessionManagement
	.concurrentSessions((concurrentSessions) -> concurrentSessions
		.maximumSessions(SessionLimit.of(1))
	)
);

[jzheaux]

I wonder if a new interface is necessary in this case since we already have ServerAuthenticationSuccessHandler, whose method signature is the same.

It seems like the implementations could be added to a DelegatingServerAuthenticationSuccessHandler instance. Do you try that already?

[marcusdacoregio]

Thanks! I've changed the implementation to use the ServerAuthenticationSuccessHandler instead of a new interface.