you are correct that there is an underlying assumption that a user's roles
cannot change within a session. to solve that problem right now, you would
have to manually call Session.clear(), clearing all pagemaps in the user's
session. why do you think that would not work? (aside from
? This was the original idea that led
me
to start this thread...
--
View this message in context:
http://www.nabble.com/Is-IAuthorizationStrategy-isInstantiationAuthorized-prone-to-security-bugs--tf3299965.html#a9201709
Sent from the Wicket - Dev mailing list archive at Nabble.com.
Well, you are right. Now I see that there should be no problems with
isInstantiationAuthorized when Session.clear() is used consistently... Sorry
for my confused arguments :-)
Thanks,
Bendis
On Wednesday 28 of February 2007 11:52:01 Jonathan Locke wrote:
you're quoting me a bit out of context
but still:
session.invalidate() instead of clear() is a much better solution anyway.
johan
On 2/28/07, Martin Benda [EMAIL PROTECTED] wrote:
Well, you are right. Now I see that there should be no problems with
isInstantiationAuthorized when Session.clear() is used consistently...
Sorry
for
? This was the original idea that
led
me
to start this thread...
--
View this message in context:
http://www.nabble.com/Is-IAuthorizationStrategy-isInstantiationAuthorized-prone-to-security-bugs--tf3299965.html#a9206737
Sent from the Wicket - Dev mailing list archive at Nabble.com.
? This was the original idea that
led
me
to start this thread...
--
View this message in context:
http://www.nabble.com/Is-IAuthorizationStrategy-isInstantiationAuthorized-prone-to-security-bugs--tf3299965.html#a9206790
Sent from the Wicket - Dev mailing list archive at Nabble.com.
isinstatiationauthorized is also very important because sometimes you do
things in the constructor that have sideffects.
take a stupid example
class DeleteAllUsersPage() { public DeleteAllUsersPage() {
service.deleteallusers(); add(new label(lbl, all users deleted)); }}
by the time enable or
but instantiation authorized is does just what it says.
is the creation of a page/component possible
For extra checks you need:
/**
* @see
wicket.authorization.IAuthorizationStrategy#isActionAuthorized(
wicket.Component,
* wicket.authorization.Action)
*/
). Another question: do
we
need this fine-grained isInstantisationAuthorized(componentClass) at all?
WDYT?
Regards,
Bendis
--
View this message in context:
http://www.nabble.com/Is-IAuthorizationStrategy-isInstantiationAuthorized-prone-to-security-bugs--tf3299965.html#a9186214
Sent from
?
Regards,
Bendis
--
View this message in context:
http://www.nabble.com/Is-IAuthorizationStrategy-isInstantiationAuthorized-prone-to-security-bugs--tf3299965.html#a9186998
Sent from the Wicket - Dev mailing list archive at Nabble.com.
isInstantisationAuthorized(componentClass) at
all?
WDYT?
Regards,
Bendis
--
View this message in context:
http://www.nabble.com/Is-IAuthorizationStrategy-isInstantiationAuthorized-prone-to-security-bugs--tf3299965.html#a9186998
Sent from the Wicket - Dev mailing list archive at Nabble.com
like
isAccessAuthorized(Class? extends Page pageClass). Another question: do
we
need this fine-grained isInstantisationAuthorized(componentClass) at all?
--
View this message in context:
http://www.nabble.com/Is-IAuthorizationStrategy-isInstantiationAuthorized-prone-to-security-bugs
12 matches
Mail list logo
