Jason Carreira wrote:
You might change your tune when you're asked to integrate your CMS
product with an existing security framework...
Since my day job is to write a CMS product with a built-in security
framework that connects to LDAP/AD/NT/whatever, I don't think that'll
happen.
Especially
ED]
[mailto:[EMAIL PROTECTED]]On Behalf Of
Rickard Öberg
Sent: Thursday, January 02, 2003 2:05 PM
To: [EMAIL PROTECTED]
Subject: Re: [OS-webwork] Re: Action invocation
Chris Miller wrote:
> Remind me again why .action causes problems with declaritive security?
> Surely the real problem is that
>
> Ah well... personally I don't really care, since I have never used
> declarative security and will never use it either.
>
You might change your tune when you're asked to integrate your CMS
product with an existing security framework... Especially if it's a
large user base and they've gone
With my
help I think that we can address all the open issues, ignore all the jackass
comments, and still get all your cool ideas in.
-Pat
- Original Message -
From: "Rickard Öberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 04, 2003 6:46 AM
S
-
From: "Rickard Öberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 04, 2003 6:04 AM
Subject: Re: [OS-webwork] Re: Action invocation
> Jason Carreira wrote:
> > Creating an extra interceptor to re-create J2EE declarative security
> > is
Damn! A little late :(.
- Original Message -
From: "matt baldree" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 04, 2003 9:56 AM
Subject: Re: [OS-webwork] Re: Action invocation
> Can someone summarize the issues? If you build XWork the way
t it on WIKI?
-Matt
- Original Message -
From: "Rickard Öberg" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Saturday, January 04, 2003 8:46 AM
Subject: Re: [OS-webwork] Re: Action invocation
Jason Carreira wrote:
>>The problem with that is keeping them in syn
Mike Cannon-Brookes wrote:
I have _never_ needed to use the fact that actions can move paths, and I
would hasten to guess that 95% of WebWork users don't care either?
That might be so, yes.
Leave the option open to do both, and we'll satisfy the security problems
(by pinning paths).
Make the
On 3/1/03 7:25 PM, "Rickard Öberg" ([EMAIL PROTECTED]) penned the words:
> Mike Cannon-Brookes wrote:
>> Hrm - no, this is thinking the wrong way mate :)
>>
>> If webwork defined paths, security would work perfectly right?
>>
>> So why not have webwork only 'work' if the path is correct (and def
Jason Carreira wrote:
The problem with that is keeping them in sync. I'd prefer
using one file
with namespaces instead.
I'm planning on using Xdoclet, I don't know about you. :-)
I'd probably use runtime attributes where possible, which is basically
the same thing. That does take care of som
> -Original Message-
> From: Rickard Öberg [mailto:[EMAIL PROTECTED]]
>
> The problem with that is keeping them in sync. I'd prefer
> using one file
> with namespaces instead.
I'm planning on using Xdoclet, I don't know about you. :-)
-
Jason Carreira wrote:
Creating an extra interceptor to re-create J2EE declarative security
is at least some extra machinery compared to just using what is
there. I'm not saying that it's bad, in fact I kind of like the idea
of restricting which roles can run packages of actions, but I would
prefer
> -Original Message-
> From: Rickard Öberg [mailto:[EMAIL PROTECTED]]
>
> Chris Nokleberg wrote:
> >>Here's another way: define the roles that are allowed to access an
> >>action in xwork.xml, and create an interceptor that checks
> it. Then it
> >>can work exactly like how web.xml wo
Chris Nokleberg wrote:
Here's another way: define the roles that are allowed to access an
action in xwork.xml, and create an interceptor that checks it. Then it
can work exactly like how web.xml works, except it can do so for the
case where an unsecure action calls a secure action too.
That is
On Fri, Jan 03, 2003 at 09:25:43AM +0100, Rickard Öberg wrote:
> Mike Cannon-Brookes wrote:
> >Hrm - no, this is thinking the wrong way mate :)
> >
> >If webwork defined paths, security would work perfectly right?
> >
> >So why not have webwork only 'work' if the path is correct (and defined)?
> >
Mike Cannon-Brookes wrote:
Hrm - no, this is thinking the wrong way mate :)
If webwork defined paths, security would work perfectly right?
So why not have webwork only 'work' if the path is correct (and defined)?
Ie /admin/foo.action would execute foo, but /bar/admin/foo.action would
execute no
May be we can add explicit url to action mapping instead of relying on using
the success view. For e.g, something like:
Or that can be implemented as part of a servlet filter configuration.
Regards,
Low
--- Rickard_Öberg <[EMAIL PROTECTED]> wrote:
> Chris Miller wrote:
> > Remind me again
Hrm - no, this is thinking the wrong way mate :)
If webwork defined paths, security would work perfectly right?
So why not have webwork only 'work' if the path is correct (and defined)?
Ie /admin/foo.action would execute foo, but /bar/admin/foo.action would
execute nothing.
That way you keep .a
Jason Carreira wrote:
You can put a declarative security line for */deleteUser.action,
can't you? Not to say that this is good, in fact it's horrible, but
at least it COULD work.
No, such expressions are not allowed by the servlet spec.
/Rickard
--
:05 PM
> To: [EMAIL PROTECTED]
> Subject: Re: [OS-webwork] Re: Action invocation
>
>
> Chris Miller wrote:
> > Remind me again why .action causes problems with
> declaritive security?
> > Surely the real problem is that Webwork currently doesn't
> care if an
Chris Miller wrote:
Remind me again why .action causes problems with declaritive security?
Surely the real problem is that Webwork currently doesn't care if an
arbitrary path is specified in the URL. ie:
http://www.me.com/abc123/admin/deleteUser.action is treated the same as
http://www.me.com/admi
> Ok. Damn. Removing .action invocations would have made things much
> simpler, especially for the declarative security users.
Remind me again why .action causes problems with declaritive security?
Surely the real problem is that Webwork currently doesn't care if an
arbitrary path is specified in
22 matches
Mail list logo
