Thomas,
On 1/13/16 1:04 PM, Thomas Scheffler wrote:
> Am 13.01.16 um 15:48 schrieb Christopher Schultz:
>> Thomas,
>>
>> On 1/13/16 8:31 AM, Thomas Scheffler wrote:
>>> Am 12.01.16 um 13:24 schrieb Mark Thomas:
On 12/01/2016 11:06, Thomas Scheffler wrote:
> Am 11.01.16 um 22:05 schrieb Ma
Am 13.01.16 um 15:48 schrieb Christopher Schultz:
Thomas,
On 1/13/16 8:31 AM, Thomas Scheffler wrote:
Am 12.01.16 um 13:24 schrieb Mark Thomas:
On 12/01/2016 11:06, Thomas Scheffler wrote:
Am 11.01.16 um 22:05 schrieb Mark Thomas:
Found on
http://www.tomcatexpert.com/blog/2011/04/25/sessi
Thomas,
On 1/13/16 8:31 AM, Thomas Scheffler wrote:
> Am 12.01.16 um 13:24 schrieb Mark Thomas:
>> On 12/01/2016 11:06, Thomas Scheffler wrote:
>>> Am 11.01.16 um 22:05 schrieb Mark Thomas:
>
> className="org.apache.catalina.authenticator.BasicAuthenticator"
> changeSessionIdO
Am 12.01.16 um 13:24 schrieb Mark Thomas:
On 12/01/2016 11:06, Thomas Scheffler wrote:
Am 11.01.16 um 22:05 schrieb Mark Thomas:
Found on
http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection
the description how to switch the "feature" off.
I will file two bugs soon descri
On 12/01/2016 15:57, Thomas Scheffler wrote:
> What I read in the specification is that a *fix* could be implemented
> that would a allow the bug to disappear. The third point above, changing
> the sessionId only if the user is "new" to the session, would fix the
> problem, could be integrated easi
Hi Christopher,
Thanks for reminding me of my extra doubt that I missed writing of in
the first post:
Picking up on AOL: If I'm on proxy1 now, with many other users - will I
stay on that proxy for a long time? Or will I be loadbalanced to many
other proxies during my visit on the site? There's no
On 1/12/2016 10:57 AM, Thomas Scheffler wrote:
Am 12.01.16 um 14:41 schrieb Mark Thomas:
1.) are not required as every request belonging to the same session
are
already authenticated. After login() other request of the same session
will not return 'null' on getRemoteUser() or getUserPrincipal()
On 12.01.2016 12:06, Thomas Scheffler wrote:
Am 11.01.16 um 22:05 schrieb Mark Thomas:
Found on
http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection
the description how to switch the "feature" off.
I will file two bugs soon describing the issues I had. Hopefully they
will
Am 12.01.16 um 14:41 schrieb Mark Thomas:
1.) are not required as every request belonging to the same session are
already authenticated. After login() other request of the same session
will not return 'null' on getRemoteUser() or getUserPrincipal()
2.) are not required, as authenticate() use the
Olaf,
On 1/11/16 4:12 PM, Olaf Kock wrote:
> Well, at least you do a bit of protection instead of just disabling the
> session fixation security filter. However, be aware that potentially
> many people might come from the same IP address - either because it's a
> NATing home router or a big compan
Thomas,
On 1/12/16 8:03 AM, Thomas Scheffler wrote:
> Am 12.01.16 um 13:24 schrieb Mark Thomas:
>> On 12/01/2016 11:06, Thomas Scheffler wrote:
>>> Am 11.01.16 um 22:05 schrieb Mark Thomas:
>
> className="org.apache.catalina.authenticator.BasicAuthenticator"
> changeSessionIdO
On 12/01/2016 13:03, Thomas Scheffler wrote:
> Am 12.01.16 um 13:24 schrieb Mark Thomas:
>> On 12/01/2016 11:06, Thomas Scheffler wrote:
>>> Am 11.01.16 um 22:05 schrieb Mark Thomas:
For the first the description above isn't clear enough to be sure
exactly what you are asking for. Howe
Thomas
> -Original Message-
> From: Olaf Kock [mailto:tom...@olafkock.de]
> Sent: Monday, January 11, 2016 4:12 PM
> To: Tomcat Users List
> Subject: Re: Tomcat 8.0.30 Session lost
>
> Well, at least you do a bit of protection instead of just disabling the
> s
Am 12.01.16 um 13:24 schrieb Mark Thomas:
On 12/01/2016 11:06, Thomas Scheffler wrote:
Am 11.01.16 um 22:05 schrieb Mark Thomas:
Found on
http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection
the description how to switch the "feature" off.
I will file two bugs soon descri
On 12/01/2016 11:06, Thomas Scheffler wrote:
> Am 11.01.16 um 22:05 schrieb Mark Thomas:
>>>
>>> >>changeSessionIdOnAuthentication="false" />
>>>
>>> Found on
>>> http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection
>>> the description how to switch the "feature" off.
>>>
>>>
Am 11.01.16 um 22:05 schrieb Mark Thomas:
Found on
http://www.tomcatexpert.com/blog/2011/04/25/session-fixation-protection
the description how to switch the "feature" off.
I will file two bugs soon describing the issues I had. Hopefully they
will be fixed.
1.) if using HttpServetRequest.logi
Well, at least you do a bit of protection instead of just disabling the
session fixation security filter. However, be aware that potentially
many people might come from the same IP address - either because it's a
NATing home router or a big company's proxy server. Especially if you
want to attack s
On 11/01/2016 20:52, Thomas Scheffler wrote:
> Am 11.01.16 um 12:21 schrieb André Warnier (tomcat):
>> So the solution in your case, is to make sure, in your application
>> logic, that the first unauthenticated request would be totally processed
>> by the server, and the response processed by the c
Am 11.01.16 um 12:21 schrieb André Warnier (tomcat):
So the solution in your case, is to make sure, in your application
logic, that the first unauthenticated request would be totally processed
by the server, and the response processed by the client, before the
client sends a second request.
If yo
Thomas,
On 11.01.2016 11:30, Thomas Scheffler wrote:
Am 08.01.16 um 17:02 schrieb Christopher Schultz:
Tomcat will change the session identifier when the user authenticates.
If you are creating a session before login, you'll see that the session
id changes when authentication is successful. Thi
Am 08.01.16 um 17:02 schrieb Christopher Schultz:
Tomcat will change the session identifier when the user authenticates.
If you are creating a session before login, you'll see that the session
id changes when authentication is successful. This is to protect against
session-fixation attacks.
I r
2016-01-08 19:02 GMT+03:00 Christopher Schultz :
> Thomas,
>
> On 1/8/16 8:00 AM, Thomas Scheffler wrote:
>> Am 08.01.16 um 11:43 schrieb Olaf Kock:
>>> Is there any chance that the first and correctly authenticated cookies
>>> (despite the debug output "secure=false") are https-only cookies and
>>
Thomas,
On 1/8/16 8:00 AM, Thomas Scheffler wrote:
> Am 08.01.16 um 11:43 schrieb Olaf Kock:
>> Is there any chance that the first and correctly authenticated cookies
>> (despite the debug output "secure=false") are https-only cookies and
>> won't get transmitted in http, thus triggering new sessi
Am 08.01.16 um 14:03 schrieb André Warnier (tomcat):
Hi Thomas.
It is a bit difficult to figure out where the problem really is, without
having the full picture of what is going on (your web.xml configuration,
the order and precise timing in which requests really happen etc.).
But one thing I wo
On 08.01.2016 10:07, Thomas Scheffler wrote:
Hi,
I have a very rare problem regarding session handling. It is reproducible only
on a single
server environment. Of cause this is the productive server.
I use container authentication and for simplicity 'tomcat-user.xml'.
Login is done via HttpSe
Am 08.01.16 um 11:43 schrieb Olaf Kock:
Is there any chance that the first and correctly authenticated cookies
(despite the debug output "secure=false") are https-only cookies and
won't get transmitted in http, thus triggering new sessions? E.g. any
chance they get rewritten at another level (Apa
Is there any chance that the first and correctly authenticated cookies
(despite the debug output "secure=false") are https-only cookies and
won't get transmitted in http, thus triggering new sessions? E.g. any
chance they get rewritten at another level (Apache httpd, ServletFilter,
others) to be se
27 matches
Mail list logo
