SeasideSt
Figure out configuration of session filters
Currently it is not possible to configure filters from the web.
Original issue reported on code.google.com by renggli on 27 Dec 2008 at 12:43
Related comment from the mailing-list: Ah, thanks. It just felt odd that it is
possible to add
WAAuthConfiguration with login and password via the web interface but that
there is no way to actually activate
the authentication mechanism.
Original comment by renggli on 27 Dec 2008 at 3:46
- Added labels: ****
- Removed labels: ****
Session filters can presumably be added relatively simply by just adding a
configuration option and having
Application add all the filters to the Session. It seems like EntryPoint
filters should be added and removed
directly to the EntryPoint, not with a configuration option...?
Original comment by [email protected] on 27 Dec 2008 at 4:41
- Added labels: ****
- Removed labels: ****
Original comment by renggli on 3 Jan 2009 at 10:16
- Added labels: Milestone-2.9b1
- Removed labels: ****
Original comment by [email protected] on 22 Feb 2009 at 12:22
- Added labels: Priority-High
- Removed labels: Priority-Medium
Original comment by [email protected] on 27 Feb 2009 at 7:33
- Added labels: Type-Defect
- Removed labels: Type-Feature
I made it technically possible to configure filters themselves (but not to add
or
remove filters to a handler) with the following:
Name: Seaside-Tests-WebTools-jf.6
Author: jf
Time: 4 March 2009, 10:04:01 pm
UUID: 2c3e307a-e9c5-4293-b7b8-c5dfccf04bf7
Ancestors: Seaside-Tests-WebTools-lr.5
Name: Seaside-WebTools-jf.21
Author: jf
Time: 4 March 2009, 10:04:07 pm
UUID: 68a2fa01-ec9d-4d65-87fa-f0cb5cd05539
Ancestors: Seaside-WebTools-jf.20
Original comment by [email protected] on 4 Mar 2009 at 9:09
- Added labels: ****
- Removed labels: ****
I do not expect to work on this issue further myself in the near future as this
code
has beaten me into submission. Hopefully the refactored code will give someone
else
enough headstart to make serious headway before their will is broken.
Original comment by [email protected] on 4 Mar 2009 at 9:11
- Added labels: ****
- Removed labels: ****
Original comment by [email protected] on 4 Sep 2009 at 8:33
- Added labels: Milestone-3.0b1
- Removed labels: ****
Original comment by [email protected] on 4 Sep 2009 at 8:38
- Added labels: ****
- Removed labels: Milestone-2.9b1
Original comment by renggli on 8 Sep 2009 at 7:09
- Added labels: Version-Seaside3.0
- Removed labels: ****
Original comment by renggli on 8 Sep 2009 at 7:10
- Added labels: ****
- Removed labels: Version-Seaside2.9
Original comment by [email protected] on 20 Sep 2009 at 6:12
- Changed state: Started
- Added labels: ****
- Removed labels: ****
Gerhard, do you have a plan of attack in mind (just reviewing bugs for beta...)?
Original comment by [email protected] on 21 Sep 2009 at 9:08
- Added labels: ****
- Removed labels: ****
Thats a good question
1) Doing some anlysis (currently work in progress)
2) Improve the current UI (see my prototype)
3) Add new functionality to address open issues (open for suggestions)
4) Refactoring, Reviewing, Testing ,...
I am not sure if it could be finished for the next beta.
Original comment by [email protected] on 22 Sep 2009 at 5:32
- Added labels: ****
- Removed labels: ****
I made it possible to add and remove WARequestFilter instances.
Well, I have now some open issues:
- Is it really necessary to configure every Filter class?
If not which filter class are necessary
- Which attributes should be configured?
Are there any default values, predefined options, ..
- To continue with my work I need some examples how to set up such filters
correctly
Original comment by [email protected] on 27 Sep 2009 at 3:39
- Added labels: ****
- Removed labels: ****
Well, the filters that are configurable should use Configurations, right? That
would be the hope anyway...
I think you're right that some filters won't really make sense to be configured
in a generic way. This is partly
what I was getting at with a task-based interface I guess... you could have
tasks that added and configured
filters for certain desired behaviours. There aren't a lot of filters written
yet, of course, so it's a bit hard to say (I
realize this isn't very helpful for you :) ).
Original comment by [email protected] on 27 Sep 2009 at 4:04
- Added labels: ****
- Removed labels: ****
- Now WAAuthenticationFilter and WAExceptionFilter are fully configurable.
(Prototype is stored at seaside29Addons)
- All others can be removed only.
- Didnt get WAAuthenticationFilter to work, because if I try to open an
EntryPoint
with an authentication filter , I'll get an exception "WAAttribute not found".
The "login" attribute is not found, but its definitely part of the user configs.
There seems to be a lookup issue with it!
Original comment by [email protected] on 27 Sep 2009 at 6:54
- Added labels: ****
- Removed labels: ****
I'm not exactly sure what you mean about AuthenticationFilter. It's designed to
be pluggable with an
"authenticator" that implements #verifyPassword:forUser:, the default for which
is the request handler that is
being filtered. The default implementation of #verifyPassword:forUser: looks
for a configuration attribute
provided by WAAuthConfiguration.
It probably doesn't make sense to allow configuring the authenticator instance
variable from the web ui since
that is a pretty advanced use case, though.
I suppose you could make an argument to have the auth filter use itself as the
default authenticator instead of
the request handler (in which case the Realm should be added as a configuration
attribute). We were trying to
make it easy for people to support authentication against existing databases or
with multiple
users/passwords, but maybe it's just as easy for them to create their own
filter...
Original comment by [email protected] on 27 Sep 2009 at 9:06
- Added labels: ****
- Removed labels: ****
Oh, by the way, it's not very clearly explained in the issues description but a
big part of this issue is the
configuration of filters that need to live on sessions. We're not sure how to
support that since sessions or
created on demand...
Original comment by [email protected] on 27 Sep 2009 at 9:12
- Added labels: ****
- Removed labels: ****
- Remove for all filters is possible
- Only WAExceptionFilter is configurable in the moment
- If filters which should be configurable use Configurations, it will be easy
to make
such filters configurable
Since the requirements seems to be not well defined I can't continue to work on
this
issue furthermore.
Original comment by [email protected] on 29 Sep 2009 at 5:54
- Changed state: Accepted
- Added labels: ****
- Removed labels: ****
Original comment by [email protected] on 26 Jan 2010 at 10:05
- Added labels: Milestone-3.1
- Removed labels: Milestone-3.0b1
What's the current state of this?
Original comment by [email protected] on 29 Jan 2011 at 10:32
- Added labels: ****
- Removed labels: ****
IMHO this is implemented, WAStrictTransportSecurityFilter is configurable just
by extending WAConfiguredRequestFilter, no additional configuration or setup
needed. If nobody objects I would close this.
Original comment by [email protected] on 30 Jan 2011 at 1:25
- Added labels: ****
- Removed labels: ****
Well, I still think the main point of the issue was the ability to configure
session filters. Does the application hold a configuration instance for them
that is either copied or shared by each filter instance? Does it hold a
prototypical filter that is that is copied and added to each session?
Original comment by [email protected] on 31 Jan 2011 at 11:06
- Changed title: Figure out configuration of session filters
- Added labels: ****
- Removed labels: ****