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]>> 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>
>>>
>>>
>>> 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>
>>>
>>>
>>>
>>> -------------------------------------------------------
>>> 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
>>>
>>>
>>
>>
>> -------------------------------------------------------
>> 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
>>
>
>
> -------------------------------------------------------
> 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
<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
-------------------------------------------------------
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
