Re: [Wicket-user] Removal of ISecuritySettings.get/setSignInPage()
fine by me but should we make a SimplePageUnauthorizedComponentInstantiationListener(SignIn.class); to simplify itfor usersthen they can do (libray example:) getSecuritySettings().setUnauthorizedComponentInstantiationListener(new SimplePageUnauthorizedComponentInstantiationListener(
SignIn.class); // Create a simple authorization strategy, that checks all pages of type // Authenticated web page. SimplePageAuthorizationStrategy authorizationStrategy = new SimplePageAuthorizationStrategy(
AuthenticatedWebPage.class) { protected boolean isAuthorized() {// check whether the user is logged onreturn (((LibrarySession)Session.get()).isSignedIn());
} };Then for all the setSiginPage() users it is jus a matter of relacing it with the above.johanOn 2/14/06,
Eelco Hillenius [EMAIL PROTECTED] wrote:
Yeah. Another problem with having an application level signin pagesetting is that there might be multiple instead of just one (e.gdepending of the level of authentication, think of how how manybanking apps work), and that authentication might be done outside of
Wicket, in which case you'd rather redirect to a url.EelcoOn 2/13/06, Jonathan Locke [EMAIL PROTECTED] wrote: Eelco tells me that a couple people are complaining about this change and I
wanted to explain why it happened and also reassure everyone that the big bunch of changes that just went through is the last of what I wanted to get done for 1.2.From here on out, I'd like to see us just fix bugs and
improve the examples and documentation for what we've got. The problem with the sign-in page setting is that (a) it's magical in nature and a bunch of stuff happens behind the scenes that is hard to find and
extend and (b) the setting will not necessarily be respected by Wicket in the future.In fact, if you use the wicket-auth-roles-examples project's authentication package (which I'm hoping will be moved into core in
2.0 when we adopt Java 5), the setting is totally ignored.This becomes very confusing to users who think that the sign-in page is a contract with wicket for authentication.It isn't and cannot be.Igor complained about this and
I agreed with his complaint and so it was removed. The big long scary names of those classes reflect exactly what the classes do.However, nobody really needs to use them directly.The intent of
wicket-auth-roles-examples (we could move this into wicket-auth-roles for 1.2 final if people like that idea) is to make a really simple way to do authentication in Wicket that is (a) not magical and (b) highly extensible
and (c) does not require that you understand much about how it works. Please check out my blog on JRoller where I very briefly discuss this code. And let us know if this is a better approach to authentication.It's my
strong feeling that it is a huge improvement over get/setSignInPage. Best,Jonathan---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 makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___Wicket-user mailing listWicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Removal of ISecuritySettings.get/setSignInPage()
sure. but call it something more like UnauthorizedPageInstantiationRedirector or even just SimpleAuthenticator.On 2/14/06, Johan Compagner
[EMAIL PROTECTED] wrote:fine by me but should we make a SimplePageUnauthorizedComponentInstantiationListener(
SignIn.class); to simplify itfor usersthen they can do (libray example:) getSecuritySettings().setUnauthorizedComponentInstantiationListener(new SimplePageUnauthorizedComponentInstantiationListener(
SignIn.class); // Create a simple authorization strategy, that checks all pages of type // Authenticated web page. SimplePageAuthorizationStrategy authorizationStrategy = new SimplePageAuthorizationStrategy(
AuthenticatedWebPage.class) { protected boolean isAuthorized() {// check whether the user is logged onreturn (((LibrarySession)Session.get()).isSignedIn());
} };Then for all the setSiginPage() users it is jus a matter of relacing it with the above.johan
On 2/14/06,
Eelco Hillenius [EMAIL PROTECTED] wrote:
Yeah. Another problem with having an application level signin pagesetting is that there might be multiple instead of just one (e.gdepending of the level of authentication, think of how how manybanking apps work), and that authentication might be done outside of
Wicket, in which case you'd rather redirect to a url.EelcoOn 2/13/06, Jonathan Locke
[EMAIL PROTECTED] wrote: Eelco tells me that a couple people are complaining about this change and I
wanted to explain why it happened and also reassure everyone that the big bunch of changes that just went through is the last of what I wanted to get done for 1.2.From here on out, I'd like to see us just fix bugs and
improve the examples and documentation for what we've got. The problem with the sign-in page setting is that (a) it's magical in nature and a bunch of stuff happens behind the scenes that is hard to find and
extend and (b) the setting will not necessarily be respected by Wicket in the future.In fact, if you use the wicket-auth-roles-examples project's authentication package (which I'm hoping will be moved into core in
2.0 when we adopt Java 5), the setting is totally ignored.This becomes very confusing to users who think that the sign-in page is a contract with wicket for authentication.It isn't and cannot be.Igor complained about this and
I agreed with his complaint and so it was removed. The big long scary names of those classes reflect exactly what the classes do.However, nobody really needs to use them directly.The intent of
wicket-auth-roles-examples (we could move this into wicket-auth-roles for 1.2 final if people like that idea) is to make a really simple way to do authentication in Wicket that is (a) not magical and (b) highly extensible
and (c) does not require that you understand much about how it works. Please check out my blog on JRoller where I very briefly discuss this code. And let us know if this is a better approach to authentication.It's my
strong feeling that it is a huge improvement over get/setSignInPage. Best,Jonathan---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 makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Removal of ISecuritySettings.get/setSignInPage()
then i prefer SimplePageAuthenticator to be in line wit hthe SimplePageAuthroizationStrategy.But then we have a name that is not directly logical to throw into a setUnauthorizedComponentInstantiationListener
But i guess its fine.On 2/14/06, Jonathan Locke [EMAIL PROTECTED] wrote:
sure. but call it something more like UnauthorizedPageInstantiationRedirector or even just SimpleAuthenticator.
On 2/14/06, Johan Compagner
[EMAIL PROTECTED] wrote:fine by me but should we make a SimplePageUnauthorizedComponentInstantiationListener(
SignIn.class); to simplify itfor usersthen they can do (libray example:) getSecuritySettings().setUnauthorizedComponentInstantiationListener(new SimplePageUnauthorizedComponentInstantiationListener(
SignIn.class); // Create a simple authorization strategy, that checks all pages of type // Authenticated web page. SimplePageAuthorizationStrategy authorizationStrategy = new SimplePageAuthorizationStrategy(
AuthenticatedWebPage.class) { protected boolean isAuthorized() {// check whether the user is logged onreturn (((LibrarySession)Session.get()).isSignedIn());
} };Then for all the setSiginPage() users it is jus a matter of relacing it with the above.johan
On 2/14/06,
Eelco Hillenius [EMAIL PROTECTED] wrote:
Yeah. Another problem with having an application level signin pagesetting is that there might be multiple instead of just one (e.gdepending of the level of authentication, think of how how manybanking apps work), and that authentication might be done outside of
Wicket, in which case you'd rather redirect to a url.EelcoOn 2/13/06, Jonathan Locke
[EMAIL PROTECTED] wrote: Eelco tells me that a couple people are complaining about this change and I
wanted to explain why it happened and also reassure everyone that the big bunch of changes that just went through is the last of what I wanted to get done for 1.2.From here on out, I'd like to see us just fix bugs and
improve the examples and documentation for what we've got. The problem with the sign-in page setting is that (a) it's magical in nature and a bunch of stuff happens behind the scenes that is hard to find and
extend and (b) the setting will not necessarily be respected by Wicket in the future.In fact, if you use the wicket-auth-roles-examples project's authentication package (which I'm hoping will be moved into core in
2.0 when we adopt Java 5), the setting is totally ignored.This becomes very confusing to users who think that the sign-in page is a contract with wicket for authentication.It isn't and cannot be.Igor complained about this and
I agreed with his complaint and so it was removed. The big long scary names of those classes reflect exactly what the classes do.However, nobody really needs to use them directly.The intent of
wicket-auth-roles-examples (we could move this into wicket-auth-roles for 1.2 final if people like that idea) is to make a really simple way to do authentication in Wicket that is (a) not magical and (b) highly extensible
and (c) does not require that you understand much about how it works. Please check out my blog on JRoller where I very briefly discuss this code. And let us know if this is a better approach to authentication.It's my
strong feeling that it is a huge improvement over get/setSignInPage. Best,Jonathan---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 makessearching your log files as easy as surfing theweb.DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmdlnkkid3432bid#0486dat1642___Wicket-user mailing list
Wicket-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wicket-user
Re: [Wicket-user] Removal of ISecuritySettings.get/setSignInPage()
yes that is for SimplePageAuthorizationStrategy even easier to use. Only one thing to do/create.johanOn 2/14/06, Mark Derricutt [EMAIL PROTECTED] wrote:On 2/14/06, Johan Compagner [EMAIL PROTECTED] wrote: then i prefer SimplePageAuthenticator to be in line wit hthe SimplePageAuthroizationStrategy.But then we have a name that is not directly logical to throw into a setUnauthorizedComponentInstantiationListener But i guess its fine.In my small app I've just made my SimplePageAuthroizationStrategy based class implement IUnauthorizedComponentInstantiationListener and then:myauth = new MyAuth(); setAuthenticationStrategy(myauth);setUnauthorizedComponentInstantiationListener(myauth);It keeps the logic in the same place which suites me.-- i like my video games - mamma said they are gonna melt my brains i like my video games - i don't care what daddy said; they're my reality- henning pauly
[Wicket-user] Removal of ISecuritySettings.get/setSignInPage()
Eelco tells me that a couple people are complaining about this change and I wanted to explain why it happened and also reassure everyone that the big bunch of changes that just went through is the last of what I wanted to get done for 1.2. From here on out, I'd like to see us just fix bugs and improve the examples and documentation for what we've got.The problem with the sign-in page setting is that (a) it's magical in nature and a bunch of stuff happens behind the scenes that is hard to find and extend and (b) the setting will not necessarily be respected by Wicket in the future. In fact, if you use the wicket-auth-roles-examples project's authentication package (which I'm hoping will be moved into core in 2.0 when we adopt Java 5), the setting is totally ignored. This becomes very confusing to users who think that the sign-in page is a contract with wicket for authentication. It isn't and cannot be. Igor complained about this and I agreed with his complaint and so it was removed. The big long scary names of those classes reflect exactly what the classes do. However, nobody really needs to use them directly. The intent of wicket-auth-roles-examples (we could move this into wicket-auth-roles for 1.2 final if people like that idea) is to make a really simple way to do authentication in Wicket that is (a) not magical and (b) highly extensible and (c) does not require that you understand much about how it works. Please check out my blog on JRoller where I very briefly discuss this code. And let us know if this is a better approach to authentication. It's my strong feeling that it is a huge improvement over get/setSignInPage. Best, Jonathan
