Am 31.08.2012 18:51, schrieb Mark Thomas:
> On 31/08/2012 17:37, Christian Beikov wrote:
>> My main question was about whether there is a way to retrieve the https
>> port of the EE6/Servlet Container in a standard way? If not maybe a
>> method to convert an URL in a standard way to use https?
>>
>> Seems like there is no standard way for doing this kind of task. My use
>> case would be, to allow users to choose if they want to use https or
>> not.
> Why would you need this? The user is free to access your site via
> http://... or https://...
>
> Could you elaborate on the scenarios where this doesn't work?
Based on the preference of a user I might redirect him to the https url.
Since the ports of a web container are not necessarily known, it would
be handy if something like this is added. Otherwise the ports would have
to be configured for the target runtime. The option to configure
confidetial access for a web resource collection in web.xml is just not
dynamic enough IMO.
>> I could do that with container specific configuration at deployment
>> time too, but that would be error-prone. Antonio Goncalves also asked
>> for a Servlet/Web-Container API which I also would like to ask for, at
>> least I would request an API to be able to access some information of
>> the underlying network and management specific stuff.
> You'll need to make a much more specific request than that for it to be
> considered.
The only really useful thing I can think of is an API through which the
available ports(+ protocols) of sockets that are currently bound can be
retrieved.
>
>> I have some more things on my wishlist which I would like you to take a
>> look at.
>>
>> 1. The fact that only one session config per webapp can be configured
>> is very limiting. In the cookie config someone could configure the
>> path of the cookie, which is somehow useless IMO since you can only
>> use one session config. I think it would be nice to return the
>> session based on the current servlet path when calling
>> HttpServletRequest.getSession()
> Doesn't that defeat the whole point of a session? Separate sessions for
> different paths suggests (rather strongly to me) that you actually have
> separate web applications.
The problem is, that when webapps are packaged in in different WAR
files, they will have different context paths, configuration has to be
done multiple times etc. Of course some of the problems could be handled
by the build.
My use case is, that I want to "package" a backend webapp together with
a frontend webapp into a single WAR, which would currently break my app,
since the backend should have a different session configuration than the
frontend.
Maybe I am just thinking wrong, but I think that this is somehow a
limitation.
The main problem is in my opinion, that you can not say something like
"I have one WAR file X which is the host webapp for Y and Z". It could
be solved by allowing a WAR file to contain other WAR files for example
in WEB-INF/lib. The sub WAR files would then be "hosted" by the parent
WAR file.
It is just an idea. Since modularization becomes more and more
important, I thought of having to package everything into one WAR file
is somehow bad.
>
>> 2. Regenerating a session id is somehow painful and there should be a
>> method like regenerateId() in the HttpSession interface. Especially
>> after a login, someone might want to regenerate the session id for
>> security reasons. Current approaches(like the one ESAPI offers[1])
>> for regenerating that id are somehow inefficient due to the lack of
>> better access to the underlying session management.
> Already in hand.
Have just seen the thread for that.
>
> Mark
>