Igor Vaynberg wrote:
thats why i wanted to separate it, to avoid confusion. think about how
many extra function calls we would be doing for something that only
needs to be called once? on a page with a repater with 10 rows 10
columns there are probably over 200 components easy, do we need 200
extra method invocations that do 200 instanceof checks for nothing?
well, you could save the instanceof checks, but you are going to have
200 method invocations no matter what. even if you don't have a custom
security strategy installed, you will still be calling
authorizeInstantiation() on every single component you instantiate, no
matter what. page or not. that overhead cannot go away because it's
what guarantees that the framework is secure. so at best you're saving
some instanceof tests. but at the expense of a more confusing api. now
the framework is going to call /two/ different checks for every page.
if you're looking for performance improvements, i think you ought to
consider all the component hierarchy traversals that we do or the
efficiency of header contributions. both show up as hotspots in profiling.
i dont care where this separate method ends up living but we do need
one. if we are going to put it into the AuthorizationStrategy then
page should not call the component check.
if you do the check to make it not call component check then you're
doing the instanceof check (in the Component constructor) that you
wanted to avoid in the first place!
on a side note i never really liked the fact that a page is a
component. things like setEnabled/setVisible dont make sense in a
page. i understand why its there, maybe 2.0 can have some sort of
abstract common base thats not a full fledged component.
it's a friggin markup container! and that seems perfect to me. will
you stop trying to change everything that somehow doesn't intersect with
your own personal world view? the same energy would be better spent
trying to solve problems that would really improve the framework
-Igor
On 1/17/06, *Jonathan Locke* <[EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>> wrote:
well, pages ARE components. but even if the instanceof check is that
big of a deal, you would still put the check in the /authorization/
strategy, because that's what it is. authentication has to do with
determining who the user is, not what they can access. anyway, maybe
the thing to do is add this to IAuthorizationStrategy:
/**
* Checks whether an instance of the given component class may be
created.
* If this method returns false, a [EMAIL PROTECTED]
AuthorizationException} is
thrown
* during construction.
*
* @param componentClass
* The component class to check
* @return Whether the given component may be created
*/
boolean authorizePageInstantiation(Class componentClass);
and call this from the Page constructor. you do avoid the instanceof
check, but i wonder if that really matters. plus it becomes more
confusing. for pages, shouldn't both checks be called? after all, a
page is a component.
Igor Vaynberg wrote:
> well you didnt really address my concern of overhead. authorization
> strategy runs the check on every component that is created.
> authentication is only concerned with pages. so at minimum you
have an
> instanceof check that will run 99% for nothing. thus my
suggestion of
> a seprate interface to only check instantiation of pages and not
> components.
>
> -Igor
>
>
> On 1/17/06, *Jonathan Locke* < [EMAIL PROTECTED]
<mailto:[EMAIL PROTECTED]>
> <mailto:[EMAIL PROTECTED] <mailto:[EMAIL PROTECTED]>>> wrote:
>
>
> you would use this like this:
>
> public class MyApplication
> {
> public ISessionFactory getSessionFactory()
> {
> return new ISessionFactory()
> {
> public Session newSession()
> {
> return new Session(...)
> {
> onAuthenticate()
> {
>
> getRequestCycle().getResponsePage().redirectToInterceptPage(new
> SignInPage(...));
> }
> }
> }
> };
> }
> }
>
> the default session implementation could even redirect to
> IApplicationSettings.getSignInPage () automatically so you don't
> have to
> write this either.
>
> what happens on the sign in page would be implementation
specific, but
> it would need to set things up so that future exceptions
would not be
> thrown by the authorization strategy.
>
> Jonathan Locke wrote:
> >
> > an UnauthorizedInstantiationException could be caught and
used to
> > direct the user to a sign in page if exception.getClass()
> instanceof Page
> >
> > this would cover the more unusal case of someone following a
> link to
> > something they aren't signed in to access. "sign in", btw
is our
> > terminology and i think the preferred one for users as
"log in"
> is old
> > school and less clear in meaning.
> >
> > normal sign in probably happens on the home page.
> > the actual signing in is going to be totally dependent on your
> > authentication mechanism.
> >
> > so i'm not sure what this RFE can really accomplish and i
really
> don't
> > see how this is a strategy in nature.
> > perhaps we could provide a default exception trap that calls a
> method
> > in Session when the user tries to access a Page and an
> > UnauthorizedInstantiationException is thrown. that method
could be
> > overridden to proceed with authentication (whatever that
might be).
> > something like Session.onAuthenticate ().
> > Jonathan Locke wrote:
> >>
> >> we need to avoid confusing things. the instantiation of
a page
> >> component is also an authorization issue and is already
covered by
> >> IAuthorizationStrategy:
> >>
> >> /**
> >> * Checks whether an instance of the given component class
> may be
> >> created.
> >> * If this method returns false, a [EMAIL PROTECTED]
> AuthorizationException}
> >> is thrown
> >> * during construction.
> >> *
> >> * @param componentClass
> >> * The component class to check
> >> * @return Whether the given component may be created
> >> */
> >> boolean authorizeInstantiation(Class componentClass);
> >>
> >> if you try to instantiate a page that isn't allowed, you will
> get an
> >> UnauthorizedInstantiationException thrown with the class
in that
> >> exception.
> >>
> >> SourceForge.net wrote:
> >>> Feature Requests item #1408679, was opened at 2006-01-18
01:46
> >>> Message generated for change (Tracker Item Submitted)
made by Item
> >>> Submitter
> >>> You can respond by visiting:
> >>>
>
https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1408679&group_id=119783
<https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1408679&group_id=119783>
> <
https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1408679&group_id=119783
<https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1408679&group_id=119783>>
>
> >>>
> >>>
> >>> Please note that this message will contain a full copy
of the
> >>> comment thread,
> >>> including the initial issue submission, for this request,
> >>> not just the latest update.
> >>> Category: core
> >>> Group: 1.2
> >>> Status: Open
> >>> Priority: 5
> >>> Submitted By: Igor Vaynberg (ivaynberg)
> >>> Assigned to: Nobody/Anonymous (nobody)
> >>> Summary: time for IAuthenticationStrategy
> >>>
> >>> Initial Comment:
> >>> is it time we created an authentication strategy? we
> >>> have a pretty good authorization strategy so now we
> >>> need to fill the gap.
> >>>
> >>> the only thing i can think off is a simple interface
> >>> like this
> >>> IAuthenticationStrategy {
> >>> boolean allowPageInstantiation(Clazz page);
> >>> }
> >>>
> >>> dont know if this can really be called authentication
> >>> strategy since it really has no authentication-specific
> >>> methods in it... but we have to start somewhere
> >>>
> >>> so it might look like this:
> >>>
> >>> MyStrategy implements IAuthenticationStrategy {
> >>> boolean allowPageInstantiation(Clazz page) {
> >>> if (page instanceof LoginPage.class) {
> >>> return true;
> >>> } else if (page instanceof SecurePage) {
> >>> if (!session.isloggedin()) {
> >>> RequestCycle.get().setImmediateResponsePage(
> LoginPage.class);
> >>> }
> >>> return true;
> >>> }
> >>> }
> >>>
> >>> i think that will cover most usecases and the impl can
> >>> be pluggable.
> >>>
> >>>
> >>>
> >>>
>
----------------------------------------------------------------------
> >>>
> >>> You can respond by visiting:
> >>>
>
https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1408679&group_id=119783
<https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1408679&group_id=119783>
> <
https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1408679&group_id=119783
<https://sourceforge.net/tracker/?func=detail&atid=684978&aid=1408679&group_id=119783>>
> >>>
> >>>
> >>>
> >>> -------------------------------------------------------
> >>> This SF.net email is sponsored by: Splunk Inc. Do you
grep through
> >>> log files
> >>> for problems? Stop! Download the new AJAX search
engine that
> makes
> >>> searching your log files as easy as surfing
> the web. DOWNLOAD SPLUNK!
> >>>
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
<http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642>
>
<http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
<http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642>>
> >>>
> >>> _______________________________________________
> >>> Wicket-develop mailing list
> >>> Wicket-develop@lists.sourceforge.net
<mailto:Wicket-develop@lists.sourceforge.net>
> <mailto:Wicket-develop@lists.sourceforge.net
<mailto:Wicket-develop@lists.sourceforge.net>>
> >>> https://lists.sourceforge.net/lists/listinfo/wicket-develop
> >>>
> >>>
> >>
> >>
> >> -------------------------------------------------------
> >> This SF.net email is sponsored by: Splunk Inc. Do you
grep through
> >> log files
> >> for problems? Stop! Download the new AJAX search engine
that
> makes
> >> searching your log files as easy as surfing
the web. DOWNLOAD
> SPLUNK!
> >>
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
<http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642>
>
<http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
<http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642>>
> >> _______________________________________________
> >> Wicket-develop mailing list
> >> Wicket-develop@lists.sourceforge.net
<mailto:Wicket-develop@lists.sourceforge.net>
> <mailto:Wicket-develop@lists.sourceforge.net
<mailto:Wicket-develop@lists.sourceforge.net>>
> >>
https://lists.sourceforge.net/lists/listinfo/wicket-develop
<https://lists.sourceforge.net/lists/listinfo/wicket-develop>
> >>
> >
> >
> > -------------------------------------------------------
> > This SF.net email is sponsored by: Splunk Inc. Do you grep
> through log
> > files
> > for problems? Stop! Download the new AJAX search engine
that makes
> > searching your log files as easy as surfing
the web. DOWNLOAD
> SPLUNK!
> >
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
<http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642>
> <
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
<http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642>>
> > _______________________________________________
> > Wicket-develop mailing list
> > Wicket-develop@lists.sourceforge.net
<mailto:Wicket-develop@lists.sourceforge.net>
> <mailto:Wicket-develop@lists.sourceforge.net
<mailto:Wicket-develop@lists.sourceforge.net>>
> > https://lists.sourceforge.net/lists/listinfo/wicket-develop
> <https://lists.sourceforge.net/lists/listinfo/wicket-develop>
> >
>
>
> -------------------------------------------------------
> This SF.net email is sponsored by: Splunk Inc. Do you grep
through
> log files
> for problems? Stop! Download the new AJAX search engine
that makes
> searching your log files as easy as surfing the web. DOWNLOAD
> SPLUNK!
>
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
<http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642>
>
<http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
<http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642>>
> _______________________________________________
> Wicket-develop mailing list
> Wicket-develop@lists.sourceforge.net
<mailto:Wicket-develop@lists.sourceforge.net>
> <mailto: Wicket-develop@lists.sourceforge.net
<mailto:Wicket-develop@lists.sourceforge.net>>
> https://lists.sourceforge.net/lists/listinfo/wicket-develop
>
>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through
log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD
SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
<http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642>
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
<mailto:Wicket-develop@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wicket-develop
<https://lists.sourceforge.net/lists/listinfo/wicket-develop>
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642
_______________________________________________
Wicket-develop mailing list
Wicket-develop@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-develop
