I remember a similar discussion about session handling some time ago,
but couldn't find it anymore. I would like to start by describing how it
works today.
The http implementation is registering a single servlet context in the
container (jetty in standalone mode and an app server/servlet engine in
I recall running into approximately the same situation years and years ago,
although I can’t remember if it was for portlet applications or in Geronimo for
ears with multiple wars with servlets that forwarded from one war to another. I
think my conclusion was that the servlet spec was just wrong
Carsten
Been pondering this one some more and thrown some notes down below. Caveat to
all of them though: I am not so familiar with the recent Felix codebase in this
area; and my experience of real-world HTTP security definitely has gaps!
So my take is that some apps (obviously not many as we'r
Tom Rutchik created FELIX-5914:
--
Summary: issue with SecurityManagerEx
Key: FELIX-5914
URL: https://issues.apache.org/jira/browse/FELIX-5914
Project: Felix
Issue Type: Bug
Components:
I didn’t check for that, will take a look. The duplicate ID was what I noticed,
and one of the things tripping me up.
-R
-Original Message-
From: Carsten Ziegeler [mailto:cziege...@apache.org]
Sent: 22 August 2018 17:59
To: dev@felix.apache.org; Rob Walker
Subject: Re: Session invalidat
The new session has the same ID (and I'm not trying to imply that this
is good), but it should be a different session object being empty
Regards
Carsten
Rob Walker wrote
> What I'm seeing is that I get the same session with the same ID back, and it
> never gets invalidated. I think it has some
What I'm seeing is that I get the same session with the same ID back, and it
never gets invalidated. I think it has something to do with the wrapper not
invalidating the delegate. In our local code I've patched the wrapper to put
the delegate.invalidate() call back, and it seems then to be crea
Hmm, maybe I'm missing something here, so you call
getSession().invalidate(). This should invalidate this session and clear
all attributes.
If another request comes in using the same session id, a
getSession(false) should return null.
A getSession() should return a new session which is empty.
So
Well for the short term, I've just copied the source for HttpSessionWrapper
into our gradle re-bundling script, and just added back in the
delegate.invalidate() call at the end. So at least for now, we've got a local
solution that lets us deal with this.
I'm afraid I'm not sure what the proper
This is a problem of the http whiteboard wrt to session handling. For
each context managed by the whiteboard you get a separate session. These
sessions are managed in the real http session.
Now I assume you invalidate one of the per context managed sessions.
This does not invalidate the real http
So one more from me today - I'm a little perplexed on session invalidation.
In common with general security best practice on HTTP, we invalidate the
session ID obtained during initial logon and create a new one for the auth'd
and logged on user. This helps prevent session sniffing and spoofing b
[
https://issues.apache.org/jira/browse/FELIX-5883?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16588654#comment-16588654
]
Karl Pauls commented on FELIX-5883:
---
[~edn], I almost forgot - I added the documentatio
[
https://issues.apache.org/jira/browse/FELIX-5913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-5913:
--
Summary: Support Android (was: Felix not working with Android anymore)
> Support Android
> ---
[
https://issues.apache.org/jira/browse/FELIX-5913?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16588652#comment-16588652
]
Karl Pauls commented on FELIX-5913:
---
[~t...@phinneyridge.com], yes, that is correct. We
[
https://issues.apache.org/jira/browse/FELIX-5913?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-5913:
--
Issue Type: Wish (was: Bug)
> Felix not working with Android anymore
> ---
[
https://issues.apache.org/jira/browse/FELIX-5912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16588636#comment-16588636
]
Karl Pauls edited comment on FELIX-5912 at 8/22/18 9:54 AM:
[
[
https://issues.apache.org/jira/browse/FELIX-5912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-5912:
--
Issue Type: Improvement (was: Bug)
> Felix init error
>
>
> Key: FELI
[
https://issues.apache.org/jira/browse/FELIX-5912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls updated FELIX-5912:
--
Summary: Handle empty package definitions in system package definitions
more gracefully (was: Felix in
[
https://issues.apache.org/jira/browse/FELIX-5912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karl Pauls reassigned FELIX-5912:
-
Assignee: Karl Pauls
> Felix init error
>
>
> Key: FELIX-5912
>
[
https://issues.apache.org/jira/browse/FELIX-5912?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16588636#comment-16588636
]
Karl Pauls commented on FELIX-5912:
---
[~t...@phinneyridge.com], I'm not sure why this wo
Also wondering if others see these error messages with current Felix HTTP Jetty:
18-08-22 10:15:26 WARN - No Server set for
org.eclipse.jetty.security.ConstraintSecurityHandler@ccaf22
18-08-22 10:15:26 WARN - No Server set for
com.ascert.tas.modules.security.internal.CafeAuthHandler$1@1dea3f6
21 matches
Mail list logo
