Re: Openid integration?
Hi Nino, It is possibile to integrate spring security with the wicket swarm/ wasp software. This gives you freedom to attach any kind of authentication mechanism, including openid. We use the integration for a LDAP based integration. If you like, I have a sample on how to deal with this somewhere. Kind Regards, Olger On 3 dec 2008, at 07:31, Nino Saturnino Martinez Vazquez Wael wrote: Hmm, i'll dig into it.. Thanks.. Jan Kriesten wrote: Hi Nino, I have something working only partially though, cant get email and name attribute back from the openid provider properly.. Seems to work with openid.org, but not claimid.com or myopenid.com why not using spring-security and don't have any more hassle at all? Best regards, --- Jan. - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] -- -Wicket for love Nino Martinez Wael Java Specialist @ Jayway DK http://www.jayway.dk +45 2936 7684 - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: Wicket security: multiple login pages
Hi Sander, Two different pages for logon is possible with the spring security configuration. It's hard to see a difference based on the URL in Wicket, so Is there a way to determine in your application if you need to logon a Client or a Employee ? You could redirect to the specific logon page using an aspect. You could use something like SecurityContextHolder.getContext().getAuthentication() to check for authentication on the pages. (spring-security) Did you integrate spring-security with the wicket-security modules ? (Swarm, Wasp...) Kind Regards, Olger On 30 jan 2009, at 15:37, Sander Hofstee wrote:. Hi, I have an application with two login pages, one for employees and one for clients. Clients login with a key, employees with a username and password. I'm using wicket-security for the authorization stuff. Clients and employees have different pages, so I thought I could determine the loginpage based on the url. But so far I can't get that to work and I don't know if there are other options. Does anyone know how I can have two different loginpages in one application? Thanks, Sander. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
wicket-security now 1.4.1 compatible
Hi All, Wicket-security 1.4 SNAPSHOT is 1.4.1 compatible. We start using this internally this month, I wonder if any of you already do use the 1.4 of wicket-security ? Kind Regards, Olger - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Spring annotations fail to inject into webmodels
Did you add the listener to your spring context ?
bean id=wicketInstantiationListener
class=org.apache.wicket.injection.ComponentInjector/
On 12 sep 2009, at 11:53, pieter claassen wrote:
My abstract basewebmodel constructor from which all my webmodels
inherit
marks inself for Spring injection but still no injection takes
place. Any
suggestions where I can look?
Can I run the injection in the constructor of an abstract model from
which I
inherit all my webmodels? I cannot see why not?
Thanks in advanced.
P
BaseWebModel.java
=
...
public BaseWebModel(Long id) {
this.id = id;
InjectorHolder.getInjector().inject(this);
}
here is an example of my TemplateWebModel that uses @SpringBean to set
TemplateFactory
TemplateWebModel.java
===
...
@SpringBean(name=TemplateFactory)
private TemplateFactory templateFactory;
public TemplateWebModel(Template template) {
super(template);
}
P
On Fri, Sep 11, 2009 at 10:42 AM, jWeekend jweekend_for...@cabouge.com
wrote:
Pieter,
If you want to use Spring's @Configuarble you'll need to enable
Load Time
Weaving or Complie Time Weaving.
To use @SpringBean with an object that is not a Wicket Component
you need
to
InjectorHolder.getInjector().inject(this) on initialisation of your
object.
The benefit of the latter approach is that you do not need to
introduce
weaving and that Wicket will make sure you have a serialisable proxy
injected.
Regards - Cemal
jWeekend
OO Java Technologies, Wicket Training and Development
http://jWeekend.com
Pieter Claassen wrote:
I am using maven, spring 2.5.6, wicket 1.4 and am trying to inject
my
DAO's
into my wicket models but I find that Spring just ignores my advice.
My question:
1. @SpringBean only works on stuff that inherits from Component.
What do
I
do with things like session and models that don't? I am trying to
use
@Configurable but that is being ignored.
2. My POM deps are below. What should I pull in to have
@Configurable
working?
3. BTW. When I comment the bean out of my XML config, then I do
get an
error
so I am not sure if I am doing something very small wrong?
Thanks.
Pieter
pom.xml
===
...
dependency
groupIdorg.springframework/groupId
artifactIdspring-core/artifactId
version${spring.version}/version
/dependency
dependency
groupIdorg.apache.wicket/groupId
artifactIdwicket-spring/artifactId
version${wicket.version}/version
!--Same results whether I include or exclude the next
session--
exclusions
exclusion
groupIdorg.springframework/groupId
artifactIdspring/artifactId
/exclusion
/exclusions
/dependency
TemplateWebModel.java
==
.
@Configurable
public class TemplateWebModel extends
AbstractDataSetWebModelTemplate {
private TemplateFactory templateFactory;
public TemplateFactory getTemplateFactory() {
return templateFactory;
}
public void setTemplateFactory(TemplateFactory templateFactory) {
throw new RuntimeException(REACHED TEMPLATE FACTORY
SET); //This
setter is never run
//this.templateFactory = templateFactory;
}
.
WicketApplicationDefinitition.xml
==
?xml version=1.0 encoding=UTF-8?
beans xmlns=http://www.springframework.org/schema/beans;
xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns:context=http://www.springframework.org/schema/context
xsi:schemaLocation=
http://www.springframework.org/schema/beans
http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
http://www.springframework.org/schema/context
http://www.springframework.org/schema/context/spring-
context-2.5.xsd
context:annotation-config/
!--aop:aspectj-autoproxy/--
!-- a bean that supplies my primary application database client --
bean id=appDataSource
class=com.musmato.dao.ApplicationDBFactory
destroy-method=close
constructor-arg
ref bean=appConfig /
/constructor-arg
/bean
!-- a bean that supplies a network database client for template
uploads
--
bean id=rootDataSource class=com.musmato.dao.RootDBFactory
destroy-method=close
constructor-arg
ref bean=appConfig /
/constructor-arg
/bean
.
bean id=TemplateFactory
class=com.musmato.dao.TemplateFactory
property name=client ref=appDataSource /
/bean
--
Pieter Claassen
musmato.com
--
View this message in context:
http://www.nabble.com/Spring-annotations-fail-to-inject-into-webmodels-tp25396625p25397205.html
Sent from the Wicket - User mailing list archive at Nabble.com.
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
--
Pieter Claassen
Re: Wicket 1.4-rc6 Swarm
Hi Olivier, Till now, I kept it up to date till 1.4.3 based on snapshots. I ran into trouble with the build system and could figure out how to get that working. In the last few weeks a new version of TeamCity was installed. I'll give it another try and figure out how to create a release. We use the SNAPSHOTS in production without issues, so it should be no problem. Otherwise drop a mail. Kind Regards, Olger On 22 dec 2009, at 16:01, Olivier Bourgeois wrote: Is there any news regarding a release of Swarm 1.4 ? Because there's still only the 1.4 snapshots in the repository. For information, I'm currently using it with Wicket 1.4.3 and got no problem so far : page security and component conditional rendering works fine. 2009/7/10 Luca Provenzani eufor...@gmail.com this is a very good new! thank you a lot! Luca 2009/7/9 Olger Warnier ol...@xs4all.nl Hi Igor / List, Thanks for the trust. The wicket-security project trunk found at https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-securityis now compatible with wicket 1.4 RC6. If you have issues or comments, please let me know. I am not aware of your release rules, if you have a pointer, I could check if it is possibe to get it towards a release along with the wicket 1.4 release. Kind Regards, Olger - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: question about swarm
Hi Sam,
I have added a sample to the secureform sample where the home page creates an
anonymous class of the MySecurePage
An anonymous page has a kind of a class name. Look for a
ERROR - RequestCycle - Not authorized to instantiate class
org.apache.wicket.security.examples.secureform.pages.HomePage$2$1
org.apache.wicket.authorization.UnauthorizedInstantiationException: Not
authorized to instantiate class
org.apache.wicket.security.examples.secureform.pages.HomePage$2$1
And add the line to the hive:
permission ${ComponentPermission}
org.apache.wicket.security.examples.secureform.pages.HomePage$2$1, render,
enable;
As you can see it does not contain a line with the target response page but a
line that contains the setResponsePage call.
So you need to add a line that contains the 'name' of the anonymous class to
the hive.
Kind Regards,
Olger
On 31 dec 2009, at 02:46, Sam Barrow wrote:
I hope this is the right list for wasp/swarm.
How do i manage permissions for an anonymous subclass?
I have a page called ItemPage. I can view ItemPage, but if I try to
redirect to an anonymous subclass of ItemPage, i get an access denied
error.
this works:
setResponsePage(new CreateItemPage(getPage()));
but this doesnt:
setResponsePage(new CreateItemPage(getPage()) {
@Override
protected void onSuccess(final Serializable index) {
setResponsePage(new ViewItemPage(getBackPage(), index));
}
});
hive file:
permission ${ComponentPermission} ${pages}.CreateItemPage, inherit,
render;
permission ${ComponentPermission} ${pages}.CreateItemPage, enable;
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: question about swarm
Hi Sam Jeremy,
Together with the remark that Jeremy made - I agree, it is quite fragile - I
had a look at the code that does the checks.
I could 'assume' that an anonymous class needs the same rights as the 'normal'
class. so when your CreateItemPage has the proper rights, an anonymous variant
has the similar rights.
The other way is some kind of inheritance assumption. This needs some kind of
syntax in the hive file like the 'inherit' that is currently available. This
inherit is more page with child component 'inheritance' and not like in OO
thinking (If understand this completely).
With this in mind, I would say that treating an anonymous class as the class it
'extends' may be the best.
I tried to figure out how to recognize an anonymous class. It seems that
Class.getSimpleName = or a search to $[0-9] in getName is a solution but it
seems risky when you use a non-sun JVM.
What do you think ?
Kind Regards,
Olger
On 31 dec 2009, at 10:53, Sam Barrow wrote:
I know I can do that, but there's no way do do it by inheritance? I have
hundreds of anonymous subclasses throughout my application. Seems
sensible that subclasses should inherit their parent's permissions.
On Thu, 2009-12-31 at 10:41 +0100, Olger Warnier wrote:
Hi Sam,
I have added a sample to the secureform sample where the home page creates
an anonymous class of the MySecurePage
An anonymous page has a kind of a class name. Look for a
ERROR - RequestCycle - Not authorized to instantiate class
org.apache.wicket.security.examples.secureform.pages.HomePage$2$1
org.apache.wicket.authorization.UnauthorizedInstantiationException: Not
authorized to instantiate class
org.apache.wicket.security.examples.secureform.pages.HomePage$2$1
And add the line to the hive:
permission ${ComponentPermission}
org.apache.wicket.security.examples.secureform.pages.HomePage$2$1,
render, enable;
As you can see it does not contain a line with the target response page but
a line that contains the setResponsePage call.
So you need to add a line that contains the 'name' of the anonymous class to
the hive.
Kind Regards,
Olger
On 31 dec 2009, at 02:46, Sam Barrow wrote:
I hope this is the right list for wasp/swarm.
How do i manage permissions for an anonymous subclass?
I have a page called ItemPage. I can view ItemPage, but if I try to
redirect to an anonymous subclass of ItemPage, i get an access denied
error.
this works:
setResponsePage(new CreateItemPage(getPage()));
but this doesnt:
setResponsePage(new CreateItemPage(getPage()) {
@Override
protected void onSuccess(final Serializable index) {
setResponsePage(new ViewItemPage(getBackPage(), index));
}
});
hive file:
permission ${ComponentPermission} ${pages}.CreateItemPage, inherit,
render;
permission ${ComponentPermission} ${pages}.CreateItemPage, enable;
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: question about swarm
Hi Sam,
Found the way to solve it. It is fixed in the trunk. Still need to fix the
build server - so a check out and build of the whole is probably best.
An anonymous class will act like its' parent now.
Happy new year (to you all).
Olger
On 31 dec 2009, at 22:43, s...@sambarrow.com wrote:
In my opinion, that's how it should work; just seems like common sense to me.
Even for regular (non-anonymous) classes, it would be useful although that's
not as important.
As far as the technical part I have no idea. I've only been working with swam
for 3 days. But I will do some looking at the source code.
Sent via BlackBerry from T-Mobile
-Original Message-
From: Olger Warnier ol...@xs4all.nl
Date: Thu, 31 Dec 2009 22:35:22
To: users@wicket.apache.org
Subject: Re: question about swarm
Hi Sam Jeremy,
Together with the remark that Jeremy made - I agree, it is quite fragile - I
had a look at the code that does the checks.
I could 'assume' that an anonymous class needs the same rights as the
'normal' class. so when your CreateItemPage has the proper rights, an
anonymous variant has the similar rights.
The other way is some kind of inheritance assumption. This needs some kind of
syntax in the hive file like the 'inherit' that is currently available. This
inherit is more page with child component 'inheritance' and not like in OO
thinking (If understand this completely).
With this in mind, I would say that treating an anonymous class as the class
it 'extends' may be the best.
I tried to figure out how to recognize an anonymous class. It seems that
Class.getSimpleName = or a search to $[0-9] in getName is a solution but
it seems risky when you use a non-sun JVM.
What do you think ?
Kind Regards,
Olger
On 31 dec 2009, at 10:53, Sam Barrow wrote:
I know I can do that, but there's no way do do it by inheritance? I have
hundreds of anonymous subclasses throughout my application. Seems
sensible that subclasses should inherit their parent's permissions.
On Thu, 2009-12-31 at 10:41 +0100, Olger Warnier wrote:
Hi Sam,
I have added a sample to the secureform sample where the home page creates
an anonymous class of the MySecurePage
An anonymous page has a kind of a class name. Look for a
ERROR - RequestCycle - Not authorized to instantiate class
org.apache.wicket.security.examples.secureform.pages.HomePage$2$1
org.apache.wicket.authorization.UnauthorizedInstantiationException: Not
authorized to instantiate class
org.apache.wicket.security.examples.secureform.pages.HomePage$2$1
And add the line to the hive:
permission ${ComponentPermission}
org.apache.wicket.security.examples.secureform.pages.HomePage$2$1,
render, enable;
As you can see it does not contain a line with the target response page but
a line that contains the setResponsePage call.
So you need to add a line that contains the 'name' of the anonymous class
to the hive.
Kind Regards,
Olger
On 31 dec 2009, at 02:46, Sam Barrow wrote:
I hope this is the right list for wasp/swarm.
How do i manage permissions for an anonymous subclass?
I have a page called ItemPage. I can view ItemPage, but if I try to
redirect to an anonymous subclass of ItemPage, i get an access denied
error.
this works:
setResponsePage(new CreateItemPage(getPage()));
but this doesnt:
setResponsePage(new CreateItemPage(getPage()) {
@Override
protected void onSuccess(final Serializable index) {
setResponsePage(new ViewItemPage(getBackPage(), index));
}
});
hive file:
permission ${ComponentPermission} ${pages}.CreateItemPage, inherit,
render;
permission ${ComponentPermission} ${pages}.CreateItemPage, enable;
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
-
To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org
For additional commands, e-mail: users-h...@wicket.apache.org
Re: question about swarm
Hi Emond,
Thanks for your comments, Interesting matter. Extending ComponentPermission to
change the behavior sounds like an option.
I can't find the @InPrincipal annotation in the wicket-security project, is
this something specific ?
When you look at it from the 'hive' side: It is the standard way of working
with Swarm/Wasp, isn't it ?
That current way has a quite fragile way to define the authorization rules on
anonymous inner classes.
How to deal with that ?
Is it an option to contribute your annotations with a specific
AnnotatedPermission ? That would be really great.
Kind Regards,
Olger
On 6 jan 2010, at 12:52, Emond Papegaaij wrote:
Hi,
Your change breaks some functionality. It is now no longer possible to grant
permissions for anonymous inner classes at all, you are now forced to grant
the permission on the superclass. This might seem sensible when using a hive
file, but it is not when permissions are configured in other ways.
We create permissions by annotating components with an @InPrincipal
annotation. It is possible to create a (abstract) component and have
multiple,
anonymous subclasses, each with their own @InPrincipal annotation.
I think, this should be fixed with a special ComponentPermission: one that
does not only give permission to the specified class, but also to its
subclasses. This could be achieved by extending ComponentPermission and
overriding the implies method. The first part of the the path array should
contain the classname of the component.
Best regards,
Emond Papegaaij
On Thursday 31 December 2009 23:31:34 Olger Warnier wrote:
Hi Sam,
Found the way to solve it. It is fixed in the trunk. Still need to fix the
build server - so a check out and build of the whole is probably best. An
anonymous class will act like its' parent now.
Happy new year (to you all).
Olger
On 31 dec 2009, at 22:43, s...@sambarrow.com wrote:
In my opinion, that's how it should work; just seems like common sense to
me. Even for regular (non-anonymous) classes, it would be useful although
that's not as important.
As far as the technical part I have no idea. I've only been working with
swam for 3 days. But I will do some looking at the source code.
Sent via BlackBerry from T-Mobile
-Original Message-
From: Olger Warnier ol...@xs4all.nl
Date: Thu, 31 Dec 2009 22:35:22
To: users@wicket.apache.org
Subject: Re: question about swarm
Hi Sam Jeremy,
Together with the remark that Jeremy made - I agree, it is quite fragile
- I had a look at the code that does the checks. I could 'assume' that an
anonymous class needs the same rights as the 'normal' class. so when your
CreateItemPage has the proper rights, an anonymous variant has the
similar rights.
The other way is some kind of inheritance assumption. This needs some
kind of syntax in the hive file like the 'inherit' that is currently
available. This inherit is more page with child component 'inheritance'
and not like in OO thinking (If understand this completely). With this in
mind, I would say that treating an anonymous class as the class it
'extends' may be the best. I tried to figure out how to recognize an
anonymous class. It seems that Class.getSimpleName = or a search to
$[0-9] in getName is a solution but it seems risky when you use a non-sun
JVM.
What do you think ?
Kind Regards,
Olger
On 31 dec 2009, at 10:53, Sam Barrow wrote:
I know I can do that, but there's no way do do it by inheritance? I have
hundreds of anonymous subclasses throughout my application. Seems
sensible that subclasses should inherit their parent's permissions.
On Thu, 2009-12-31 at 10:41 +0100, Olger Warnier wrote:
Hi Sam,
I have added a sample to the secureform sample where the home page
creates an anonymous class of the MySecurePage An anonymous page has a
kind of a class name. Look for a
ERROR - RequestCycle - Not authorized to instantiate
class org.apache.wicket.security.examples.secureform.pages.HomePage$2$1
org.apache.wicket.authorization.UnauthorizedInstantiationException: Not
authorized to instantiate class
org.apache.wicket.security.examples.secureform.pages.HomePage$2$1
And add the line to the hive:
permission ${ComponentPermission}
org.apache.wicket.security.examples.secureform.pages.HomePage$2$1,
render, enable;
As you can see it does not contain a line with the target response page
but a line that contains the setResponsePage call. So you need to add a
line that contains the 'name' of the anonymous class to the hive.
Kind Regards,
Olger
On 31 dec 2009, at 02:46, Sam Barrow wrote:
I hope this is the right list for wasp/swarm.
How do i manage permissions for an anonymous subclass?
I have a page called ItemPage. I can view ItemPage, but if I try to
redirect to an anonymous subclass of ItemPage, i get an access denied
error.
this works:
setResponsePage(new CreateItemPage(getPage
Re: question about swarm
Hi Emond,
Very nice. Could you think of a way to support your scenario and a way to
support anonymous classes in a way that you don't have to specify a
MyPageClass$1$2 and we don't have to impose a change in the hive file ?
Kind Regards,
Olger
On 6 jan 2010, at 14:03, Emond Papegaaij wrote:
Hi Olger,
The InPrincipal annotation is something we developed as an alternative for
the
hive files (which we find difficult to maintain, not only with anonymous
inner
classes). Principals are defined by a set of classes with annotations
defining
things like implies relations between principals and DataPermissions.
ComponentPermissions are created by scanning for components with the
InPrincipal annotation and creating the permissions for those. We are
thinking
about releasing this code, perhaps by including it in wicket-security.
When using a hive file, you define your principals, each with a set of
permissions. Currently, you can use ComponentPermission, DataPermission and
AllPermissions. My suggestion is to add another permission that gives
permissions to a component and all of its subclasses (including anonymous
classes), something like:
permission ${ComponentSubclassPermission} MyPage, inherit, render;
This would give you permission for MyPage and its subclasses. You can define
the alias for ComponentSubclassPermission in SwarmPolicyFileHiveFactory. I
think that this is the way Swarm/Wasp is 'supposed to be used'.
Best regards,
Emond
On Wednesday 06 January 2010 13:09:09 Olger Warnier wrote:
Hi Emond,
Thanks for your comments, Interesting matter. Extending ComponentPermission
to change the behavior sounds like an option. I can't find the
@InPrincipal annotation in the wicket-security project, is this something
specific ?
When you look at it from the 'hive' side: It is the standard way of working
with Swarm/Wasp, isn't it ? That current way has a quite fragile way to
define the authorization rules on anonymous inner classes. How to deal
with that ?
Is it an option to contribute your annotations with a specific
AnnotatedPermission ? That would be really great.
Kind Regards,
Olger
On 6 jan 2010, at 12:52, Emond Papegaaij wrote:
Hi,
Your change breaks some functionality. It is now no longer possible to
grant permissions for anonymous inner classes at all, you are now forced
to grant the permission on the superclass. This might seem sensible when
using a hive file, but it is not when permissions are configured in other
ways.
We create permissions by annotating components with an @InPrincipal
annotation. It is possible to create a (abstract) component and have
multiple, anonymous subclasses, each with their own @InPrincipal
annotation.
I think, this should be fixed with a special ComponentPermission: one
that does not only give permission to the specified class, but also to
its subclasses. This could be achieved by extending ComponentPermission
and overriding the implies method. The first part of the the path array
should contain the classname of the component.
Best regards,
Emond Papegaaij
On Thursday 31 December 2009 23:31:34 Olger Warnier wrote:
Hi Sam,
Found the way to solve it. It is fixed in the trunk. Still need to fix
the build server - so a check out and build of the whole is probably
best. An anonymous class will act like its' parent now.
Happy new year (to you all).
Olger
On 31 dec 2009, at 22:43, s...@sambarrow.com wrote:
In my opinion, that's how it should work; just seems like common sense
to me. Even for regular (non-anonymous) classes, it would be useful
although that's not as important.
As far as the technical part I have no idea. I've only been working
with swam for 3 days. But I will do some looking at the source code.
Sent via BlackBerry from T-Mobile
-Original Message-
From: Olger Warnier ol...@xs4all.nl
Date: Thu, 31 Dec 2009 22:35:22
To: users@wicket.apache.org
Subject: Re: question about swarm
Hi Sam Jeremy,
Together with the remark that Jeremy made - I agree, it is quite
fragile - I had a look at the code that does the checks. I could
'assume' that an anonymous class needs the same rights as the 'normal'
class. so when your CreateItemPage has the proper rights, an anonymous
variant has the similar rights.
The other way is some kind of inheritance assumption. This needs some
kind of syntax in the hive file like the 'inherit' that is currently
available. This inherit is more page with child component 'inheritance'
and not like in OO thinking (If understand this completely). With this
in mind, I would say that treating an anonymous class as the class it
'extends' may be the best. I tried to figure out how to recognize an
anonymous class. It seems that Class.getSimpleName = or a search to
$[0-9] in getName is a solution but it seems risky when you use a
non-sun JVM.
What do you think ?
Kind Regards,
Olger
On 31 dec
Re: Wicket 1.4-rc6 Swarm
Hi Joshua / List, For our project, I have ported wicket-security to 1.4 based on the code of Maurice found at: http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/branches/wicket-security-1.4-earlyaccess/ And https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-security/ Most of the tests work fine, a few of them are disabled (I is not quite clear to me what the expected behaviour is yet) and I removed the ACEGI example as it was too outdated. (I have a spring-security sample available to add) The current state is more of less a first 'seems to work' version that needs more attention while being used and extended. Please let me know if you are intrested, I could provide the code and further suport to get it released along with the wicket 1.4 release. Kind Regards, Olger On 8 jul 2009, at 18:42, Joshua Martin wrote: When will Wicket 1.4 be compatible with Swarm/Wasp? -- _ Joshua S. Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4-rc6 Swarm
Hi Joshua / List, For our project, I have ported wicket-security to 1.4 based on the code of Maurice found at: http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/branches/wicket-security-1.4-earlyaccess/ And https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-security/ Most of the tests work fine, a few of them are disabled (I is not quite clear to me what the expected behaviour is yet) and I removed the ACEGI example as it was too outdated. (I have a spring-security sample available to add) The current state is more of less a first 'seems to work' version based on RC5 that needs more attention while being used and extended. Please let me know if you are intrested, I could provide the code and further suport to get it released along with the wicket 1.4 release. Kind Regards, Olger On 8 jul 2009, at 18:42, Joshua Martin wrote: When will Wicket 1.4 be compatible with Swarm/Wasp? -- _ Joshua S. Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4-rc6 Swarm
Hi Luca, Maybe it is possible to commit the whole into an existing / new branch of the wicket-security project. Is there someone who could arrange that ? Kind Regards, Olger On 9 jul 2009, at 11:00, Luca Provenzani wrote: Hi all, i'm interested too. Probably my company have to realize a new project in the near future and we think to use wicket 1.4, but we need something like swarm. I started to see in svn but if it is possible to have your updated code it would be fantastic. thank you Luca 2009/7/9 Olger Warnier ol...@xs4all.nl Hi Joshua / List, For our project, I have ported wicket-security to 1.4 based on the code of Maurice found at: http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/branches/wicket-security-1.4-earlyaccess/ And https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-security/ Most of the tests work fine, a few of them are disabled (I is not quite clear to me what the expected behaviour is yet) and I removed the ACEGI example as it was too outdated. (I have a spring-security sample available to add) The current state is more of less a first 'seems to work' version based on RC5 that needs more attention while being used and extended. Please let me know if you are intrested, I could provide the code and further suport to get it released along with the wicket 1.4 release. Kind Regards, Olger On 8 jul 2009, at 18:42, Joshua Martin wrote: When will Wicket 1.4 be compatible with Swarm/Wasp? -- _ Joshua S. Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4-rc6 Swarm
Hi Igor, On 9 jul 2009, at 17:13, Igor Vaynberg wrote: all you need is an account on sf.net AND for someone to add you to the project. I digged up my sourceforge account, its : terranvs If someone is willing to add my account to the project, I'll commit the whole so people can test it for their situation. Kind Regards, Olger -igor On Thu, Jul 9, 2009 at 8:06 AM, Martin Grigorovmcgreg...@e-card.bg wrote: All you need is an account for SourceForge. Then you could commit in wicketstuff's SVN El jue, 09-07-2009 a las 13:38 +0200, Olger Warnier escribió: Hi Luca, Maybe it is possible to commit the whole into an existing / new branch of the wicket-security project. Is there someone who could arrange that ? Kind Regards, Olger On 9 jul 2009, at 11:00, Luca Provenzani wrote: Hi all, i'm interested too. Probably my company have to realize a new project in the near future and we think to use wicket 1.4, but we need something like swarm. I started to see in svn but if it is possible to have your updated code it would be fantastic. thank you Luca 2009/7/9 Olger Warnier ol...@xs4all.nl Hi Joshua / List, For our project, I have ported wicket-security to 1.4 based on the code of Maurice found at: http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/branches/wicket-security-1.4-earlyaccess/ And https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-security/ Most of the tests work fine, a few of them are disabled (I is not quite clear to me what the expected behaviour is yet) and I removed the ACEGI example as it was too outdated. (I have a spring-security sample available to add) The current state is more of less a first 'seems to work' version based on RC5 that needs more attention while being used and extended. Please let me know if you are intrested, I could provide the code and further suport to get it released along with the wicket 1.4 release. Kind Regards, Olger On 8 jul 2009, at 18:42, Joshua Martin wrote: When will Wicket 1.4 be compatible with Swarm/Wasp? -- _ Joshua S. Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: Wicket 1.4-rc6 Swarm
Hi Igor / List, Thanks for the trust. The wicket-security project trunk found at https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-security is now compatible with wicket 1.4 RC6. If you have issues or comments, please let me know. I am not aware of your release rules, if you have a pointer, I could check if it is possibe to get it towards a release along with the wicket 1.4 release. Kind Regards, Olger On 9 jul 2009, at 19:38, Igor Vaynberg wrote: done -igor On Thu, Jul 9, 2009 at 10:02 AM, Olger Warnierol...@xs4all.nl wrote: Hi Igor, On 9 jul 2009, at 17:13, Igor Vaynberg wrote: all you need is an account on sf.net AND for someone to add you to the project. I digged up my sourceforge account, its : terranvs If someone is willing to add my account to the project, I'll commit the whole so people can test it for their situation. Kind Regards, Olger -igor On Thu, Jul 9, 2009 at 8:06 AM, Martin Grigorovmcgreg...@e-card.bg wrote: All you need is an account for SourceForge. Then you could commit in wicketstuff's SVN El jue, 09-07-2009 a las 13:38 +0200, Olger Warnier escribió: Hi Luca, Maybe it is possible to commit the whole into an existing / new branch of the wicket-security project. Is there someone who could arrange that ? Kind Regards, Olger On 9 jul 2009, at 11:00, Luca Provenzani wrote: Hi all, i'm interested too. Probably my company have to realize a new project in the near future and we think to use wicket 1.4, but we need something like swarm. I started to see in svn but if it is possible to have your updated code it would be fantastic. thank you Luca 2009/7/9 Olger Warnier ol...@xs4all.nl Hi Joshua / List, For our project, I have ported wicket-security to 1.4 based on the code of Maurice found at: http://wicket-stuff.svn.sourceforge.net/viewvc/wicket-stuff/branches/wicket-security-1.4-earlyaccess/ And https://wicket-stuff.svn.sourceforge.net/svnroot/wicket-stuff/trunk/wicket-security/ Most of the tests work fine, a few of them are disabled (I is not quite clear to me what the expected behaviour is yet) and I removed the ACEGI example as it was too outdated. (I have a spring-security sample available to add) The current state is more of less a first 'seems to work' version based on RC5 that needs more attention while being used and extended. Please let me know if you are intrested, I could provide the code and further suport to get it released along with the wicket 1.4 release. Kind Regards, Olger On 8 jul 2009, at 18:42, Joshua Martin wrote: When will Wicket 1.4 be compatible with Swarm/Wasp? -- _ Joshua S. Martin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: intercept security check in wicket-auth-roles
The wicket-security framework has possibilities to integrate with SSO mechanisms. Next to that, you can integrate with spring-security and all authentication mechanisms supported by that. The yahoo-bbauth sample may help you to get an idea on how that works. Olger On 11 jul 2009, at 08:09, Brill Pappin wrote: I actually find it very usable and i love how simple it is... does the new security framework have a similar simple method of securing a site like that? - Brill On 3-Jul-09, at 11:34 AM, Igor Vaynberg wrote: wicket auth roles is an example, not a reusable framework. you should copy and paste the code into your project and customize as needed. -igor On Fri, Feb 20, 2009 at 8:30 AM, Brill Pappinbr...@pappin.ca wrote: I'm trying to integrate wicket-auth-roles with a token based SSO security system. I can't see where I can intercept the authentication sequence and auto-login the user based on the token. Essentially i want to catch the authentication request and authorize the user based on a token before they are redirected to the login page. Does anyone have a clue how I might go about doing that? Unfortunately most places I've looked to over ride the sequence are marked final for some reason, which makes things difficult. I'm actually at the point now where I'm thinking of writing a new auth-roles based on the current lib, but I thought I'd ask first. ... and no, I don't want to use the other more complex security lib... auth-roles is very nice and simple to use and suitable for most applications. - Brill Pappin - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
Hi Sam, It could well be more than web-tier, but I thought if anyone has done this is would be a Wicket user :-) I looked at OSGi before I started my framework. I didn't see anything about deployment of add-ons/plug- ins. I already have a framework that incorporates IoC as a fundamental feature. Its the actual deployment of add-on functionality that interests me. ESB on first glance looks way too complicated, and I'm not sure it even does what I want. In our project we use OSGI to get a plugin structure. Interfaces defined in the 'core' layer are implemented in OSGI modules. For a simple example see: http://www.joiningtracks.org/svn/his/trunk/questionnaire/ (SVN code repo) It's a questionnaire service that uses OSGI to load the question forms (based on wicket) Our whole platform is constructed like that, the questionnaire service is the most simple one and easily adapted for your own use. Kind Regards, Olger - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
Re: best or common practice for application plug-ins
Hi Sam, How we do it with that service: We have a file listener class that checks if OSGI based jar files are put in a directory. If so, these are automatically deployed to the OSGI runtime by the BundleDeployer class. We miss a download / version updates part, but you could add that by downloading to the directory specfified by the FileListener. There is no need to restart, OSGI updates the whole automatically (we use embedded felix for this). Something to keep in mind, be careful with the OSGI versioning in this as that puts versions next to eachother. This is used to provide custom, for our project - wicket based, user interface functionality. Kind Regards, Olger On 20 jul 2009, at 12:51, Sam Stainsby wrote: OK, so I am an sys admin running some sort of OSGI-based application and now I want to add your questionnaire service and any other modules that it depends on. I also want to occasionally check for version updates. I want these updates and dependencies to be downloaded and put in the correct place for me so that when I restart the application, they are loaded. How do I do that? If it were Zope, I would add one line to a 'buildout.cfg' file and run the 'buildout' script, and restart Zope. On Mon, 20 Jul 2009 10:33:45 +0200, Olger Warnier wrote: In our project we use OSGI to get a plugin structure. Interfaces defined in the 'core' layer are implemented in OSGI modules. For a simple example see: http://www.joiningtracks.org/svn/his/trunk/ questionnaire/ (SVN code repo) It's a questionnaire service that uses OSGI to load the question forms (based on wicket) Our whole platform is constructed like that, the questionnaire service is the most simple one and easily adapted for your own use. - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org - To unsubscribe, e-mail: users-unsubscr...@wicket.apache.org For additional commands, e-mail: users-h...@wicket.apache.org
UnauthorizedActionException wrapped in an InvalidUrlException - how to deal with it ?
Hi Developers,
Slowly but surely I move through the tests of the wicket security
framework.
In one test, the SecureFormTest, i ran into some strange behaviour.
It starts with an exception like this:
org.apache.wicket.protocol.http.request.InvalidUrlException:
org.apache.wicket.authorization.UnauthorizedActionException: Component
[MarkupContainer [Component id = form]] does not permit action ENABLE
(note, the test is commented in order to prevent build failures)
There is a secureform that has no rights to be filled an submitted.
Normal behaviour till now was the return of a login page. In some
cases I found the return of the UnauthorizedActionException - all fine
till now. (running 1.4-rc7)
In this test though, I there is no redirection to a Login Page and I
can't catch the UnauthorizedActionException. This started my quest
into the originating throws, this happens to be the throw of an
InvalidUrlException in WebRequestCycleProcessor (line 248 and on)
catch (WicketRuntimeException e)
{
// we need to let page expired exception sift through instead of
covering it up
if (e instanceof PageExpiredException)
{
throw e;
}
else if (e.getCause() instanceof PageExpiredException)
{
throw e;
}
else
{
throw new InvalidUrlException(e);
}
}
The UnauthorizedActionException is catched here and thereafter thrown
wrapped in an InvalidUrlException.
This is not the end of it, the RequestCycle catches this exception and
has some logic for it (line 1337 starting) :
catch (RuntimeException e)
{
/*
* check if the raised exception wraps an abort exception. if so,
it is probably wise to
* unwrap and rethrow the abort exception
*/
Throwable cause = e.getCause();
while (cause != null)
{
if (cause instanceof AbortException)
{
throw ((AbortException)cause);
}
cause = cause.getCause();
}
if (!handlingException)
{
// set step manually to handle exception
handlingException = true;
// probably our last chance the exception can
be logged.
// Note that a PageExpiredException should not
be logged, because
// it's not an internal error
if (!(e instanceof PageExpiredException))
{
logRuntimeException(e);
}
// try to play nicely and let the request
processor handle the
// exception response. If that doesn't work,
any runtime exception
// will automatically be bubbled up
if (processor != null)
{
processor.respond(e, this);
}
}
else..
The exception runs through the cause loop, ending with a null cause,
and continues to be logged and thereafter triggers a
processor.respond(e,this) based on the InvalidUrlException.
This one is catched by the AbstractRequestCycleProcessor, doing the
following (line 116 and on):
final Application application = Application.get();
final IExceptionSettings settings =
application.getExceptionSettings();
final Page responsePage = requestCycle.getResponsePage();
Page override = onRuntimeException(responsePage, e);
if (override != null)
{
throw new RestartResponseException(override);
}
else if (e instanceof AuthorizationException)
{
// are authorization exceptions always thrown before
the real
// render?
// else we need to make a page (see below) or set it
hard to a
// redirect.
Class? extends Page accessDeniedPageClass =
application.getApplicationSettings()
.getAccessDeniedPage();
throw new
Re: UnauthorizedActionException wrapped in an InvalidUrlException - how to deal with it ?
Hi Igor,
if the form is disabled why is it allowed to be submitted?
In a test you can ;)
When you know what to submit, it is possible to submit those values
without a page, although I can imagine that it is quite hard to
achieve due to the way wicket handles form variables and stuff (via
the session).
Even with that in mind, I wonder if it is possible to have the
UnauthorizedException thrown directly (without the InvalidUrlException).
Kind Regards,
Olger
-igor
On Sun, Jul 26, 2009 at 10:58 AM, Olger Warnierol...@xs4all.nl
wrote:
Hi Developers,
Slowly but surely I move through the tests of the wicket security
framework.
In one test, the SecureFormTest, i ran into some strange behaviour.
It starts with an exception like this:
org.apache.wicket.protocol.http.request.InvalidUrlException:
org.apache.wicket.authorization.UnauthorizedActionException:
Component
[MarkupContainer [Component id = form]] does not permit action ENABLE
(note, the test is commented in order to prevent build failures)
There is a secureform that has no rights to be filled an submitted.
Normal
behaviour till now was the return of a login page. In some cases I
found the
return of the UnauthorizedActionException - all fine till now.
(running
1.4-rc7)
In this test though, I there is no redirection to a Login Page and
I can't
catch the UnauthorizedActionException. This started my quest into the
originating throws, this happens to be the throw of an
InvalidUrlException
in WebRequestCycleProcessor (line 248 and on)
catch (WicketRuntimeException e)
{
// we need to let page expired exception
sift through
instead of covering it up
if (e instanceof PageExpiredException)
{
throw e;
}
else if (e.getCause() instanceof
PageExpiredException)
{
throw e;
}
else
{
throw new InvalidUrlException(e);
}
}
The UnauthorizedActionException is catched here and thereafter thrown
wrapped in an InvalidUrlException.
This is not the end of it, the RequestCycle catches this exception
and has
some logic for it (line 1337 starting) :
catch (RuntimeException e)
{
/*
* check if the raised exception wraps an
abort
exception. if so, it is probably wise to
* unwrap and rethrow the abort exception
*/
Throwable cause = e.getCause();
while (cause != null)
{
if (cause instanceof AbortException)
{
throw ((AbortException)cause);
}
cause = cause.getCause();
}
if (!handlingException)
{
// set step manually to handle
exception
handlingException = true;
// probably our last chance the
exception can
be logged.
// Note that a PageExpiredException
should
not be logged, because
// it's not an internal error
if (!(e instanceof
PageExpiredException))
{
logRuntimeException(e);
}
// try to play nicely and let the
request
processor handle the
// exception response. If that
doesn't work,
any runtime exception
// will automatically be bubbled up
if (processor != null)
{
processor.respond(e, this);
}
}
else..
The exception runs through the cause loop, ending with a null
cause, and
continues to be logged and thereafter triggers a
processor.respond(e,this)
based on the InvalidUrlException.
This one is catched by the AbstractRequestCycleProcessor, doing the
following (line 116 and on):
final Application application = Application.get();
final IExceptionSettings settings =
application.getExceptionSettings();
final Page responsePage =
requestCycle.getResponsePage();
Page override = onRuntimeException(responsePage, e);
if (override != null)
{
throw new
Re: UnauthorizedActionException wrapped in an InvalidUrlException - how to deal with it ?
On 26 jul 2009, at 22:59, Alex Objelean wrote:
If you think this would help, then you could remove
InvalidUrlException and
invalidate the jira RFE created by me... I don't think this would
heart
anyone...
Intresting, I assume that it is of value to have this construction,
could you give me the link to the RFE ?
At any time, somehing was a WicketRuntimeException and only a
PageExpired (original or as cause) is now rethrown. All others are
wrapped.
Is there a case that in the AbstractRequestCycleProcessor the
following works then ?
else if (e instanceof AuthorizationException)
{
// are authorization exceptions always
thrown
Kind Regards,
Olger
Alex
igor.vaynberg wrote:
my point is that this case is on the fence.
it is an invalid url, and it is a security violation. so which one
should take precendence?
my other concern is that we would have to maintain a long list of
exceptions that should be passed through, which becomes a pita.
-igor
On Sun, Jul 26, 2009 at 1:32 PM, Alex Objeleanalex_objel...@yahoo.com
wrote:
I just want to remind the reason why the InvalidUrlException was
introduced:
to avoid situations when user would tweak somehow the url and get
the
InternalError Page... I introduced a request for enhancement for
InvalidUrlException feature and if there are any problems related
to it,
you
can blame me..:(
Alex Objelean
igor.vaynberg wrote:
then we are getting in a debate of what use an invalidurlexception
really is. if we forward page expired and a bunch of other
exceptions,
why do we even need an invalidurlexception...
the point is the user has submitted a form that they should not
have
been able to, it is an invalid url...
i dont know off the top of my head what the best approach is.
-igor
On Sun, Jul 26, 2009 at 12:46 PM, Olger Warnierol...@xs4all.nl
wrote:
Hi Igor,
if the form is disabled why is it allowed to be submitted?
In a test you can ;)
When you know what to submit, it is possible to submit those
values
without
a page, although I can imagine that it is quite hard to achieve
due to
the
way wicket handles form variables and stuff (via the session).
Even with that in mind, I wonder if it is possible to have the
UnauthorizedException thrown directly (without the
InvalidUrlException).
Kind Regards,
Olger
-igor
On Sun, Jul 26, 2009 at 10:58 AM, Olger Warnierol...@xs4all.nl
wrote:
Hi Developers,
Slowly but surely I move through the tests of the wicket
security
framework.
In one test, the SecureFormTest, i ran into some strange
behaviour.
It starts with an exception like this:
org.apache.wicket.protocol.http.request.InvalidUrlException:
org.apache.wicket.authorization.UnauthorizedActionException:
Component
[MarkupContainer [Component id = form]] does not permit action
ENABLE
(note, the test is commented in order to prevent build failures)
There is a secureform that has no rights to be filled an
submitted.
Normal
behaviour till now was the return of a login page. In some
cases I
found
the
return of the UnauthorizedActionException - all fine till now.
(running
1.4-rc7)
In this test though, I there is no redirection to a Login Page
and I
can't
catch the UnauthorizedActionException. This started my quest
into the
originating throws, this happens to be the throw of an
InvalidUrlException
in WebRequestCycleProcessor (line 248 and on)
catch (WicketRuntimeException e)
{
// we need to let page expired exception
sift
through
instead of covering it up
if (e instanceof PageExpiredException)
{
throw e;
}
else if (e.getCause() instanceof
PageExpiredException)
{
throw e;
}
else
{
throw new InvalidUrlException(e);
}
}
The UnauthorizedActionException is catched here and thereafter
thrown
wrapped in an InvalidUrlException.
This is not the end of it, the RequestCycle catches this
exception
and
has
some logic for it (line 1337 starting) :
catch (RuntimeException e)
{
/*
* check if the raised exception wraps
an abort
exception. if so, it is probably wise to
* unwrap and rethrow the abort exception
*/
Throwable cause = e.getCause();
while (cause != null)
{
if (cause instanceof
AbortException)
{
throw
((AbortException)cause);
}
cause = cause.getCause();
Re: UnauthorizedActionException wrapped in an InvalidUrlException - how to deal with it ?
Sorry to keep on buggin over this, I try to understand what is the
best option to plugin the unauthorized type of exceptions into the
wicket framework.
It seems (maybe because of lack of understanding) that the
UnAuthorizedException handling can't work as it is now.
Now to move on:
I've read the RFE Alex sent.
As you create a more specific extension of the runtime exception, it
will be wrapped by the WebRequestCycleProcessor to an
InvalidURLException.
How do you make sure that it will show the 404 ? (or is that default
for the InvalidURLException ?)
It might be an idea to have some kind of exception resolvement at the
spot where this decision is made. (I don't know where that is, I have
seen hints that this is already done somehow and you are able to
override it. ) and throw runtime exceptions as is to that level. By
registering exception handler pages you have the option to customize
the behaviour.
If I like to do that in the current situation, I need to handle the
InvalidUrlException, check the cause and do something only in the case
I'd like to process (Unauthorized)
What to do with the other causes of the InvalidUrl then ?
Kind Regards,
Olger
On 27 jul 2009, at 11:41, Alex Objelean wrote:
This is the link of the RFE:
https://issues.apache.org/jira/browse/WICKET-2307
Olger Warnier-2 wrote:
On 26 jul 2009, at 22:59, Alex Objelean wrote:
If you think this would help, then you could remove
InvalidUrlException and
invalidate the jira RFE created by me... I don't think this would
heart
anyone...
Intresting, I assume that it is of value to have this construction,
could you give me the link to the RFE ?
At any time, somehing was a WicketRuntimeException and only a
PageExpired (original or as cause) is now rethrown. All others are
wrapped.
Is there a case that in the AbstractRequestCycleProcessor the
following works then ?
else if (e instanceof AuthorizationException)
{
// are authorization exceptions always
thrown
Kind Regards,
Olger
Alex
igor.vaynberg wrote:
my point is that this case is on the fence.
it is an invalid url, and it is a security violation. so which one
should take precendence?
my other concern is that we would have to maintain a long list of
exceptions that should be passed through, which becomes a pita.
-igor
On Sun, Jul 26, 2009 at 1:32 PM, Alex Objeleanalex_objel...@yahoo.com
wrote:
I just want to remind the reason why the InvalidUrlException was
introduced:
to avoid situations when user would tweak somehow the url and get
the
InternalError Page... I introduced a request for enhancement for
InvalidUrlException feature and if there are any problems related
to it,
you
can blame me..:(
Alex Objelean
igor.vaynberg wrote:
then we are getting in a debate of what use an
invalidurlexception
really is. if we forward page expired and a bunch of other
exceptions,
why do we even need an invalidurlexception...
the point is the user has submitted a form that they should not
have
been able to, it is an invalid url...
i dont know off the top of my head what the best approach is.
-igor
On Sun, Jul 26, 2009 at 12:46 PM, Olger Warnierol...@xs4all.nl
wrote:
Hi Igor,
if the form is disabled why is it allowed to be submitted?
In a test you can ;)
When you know what to submit, it is possible to submit those
values
without
a page, although I can imagine that it is quite hard to achieve
due to
the
way wicket handles form variables and stuff (via the session).
Even with that in mind, I wonder if it is possible to have the
UnauthorizedException thrown directly (without the
InvalidUrlException).
Kind Regards,
Olger
-igor
On Sun, Jul 26, 2009 at 10:58 AM, Olger
Warnierol...@xs4all.nl
wrote:
Hi Developers,
Slowly but surely I move through the tests of the wicket
security
framework.
In one test, the SecureFormTest, i ran into some strange
behaviour.
It starts with an exception like this:
org.apache.wicket.protocol.http.request.InvalidUrlException:
org.apache.wicket.authorization.UnauthorizedActionException:
Component
[MarkupContainer [Component id = form]] does not permit action
ENABLE
(note, the test is commented in order to prevent build
failures)
There is a secureform that has no rights to be filled an
submitted.
Normal
behaviour till now was the return of a login page. In some
cases I
found
the
return of the UnauthorizedActionException - all fine till now.
(running
1.4-rc7)
In this test though, I there is no redirection to a Login Page
and I
can't
catch the UnauthorizedActionException. This started my quest
into the
originating throws, this happens to be the throw of an
InvalidUrlException
in WebRequestCycleProcessor (line 248 and on)
catch (WicketRuntimeException e)
{
// we need to let page expired exception
sift
through
instead of covering it up
if (e instanceof PageExpiredException
Re: UnauthorizedActionException wrapped in an InvalidUrlException - how to deal with it ?
Well, I'll add that to the WaspWebApplication and check if that will do.
Thanks.
I'll check
On 27 jul 2009, at 12:37, Alex Objelean wrote:
You can treat runtime exceptions by overriding newRequestCycle
method of
your Application class...
@Override
public Page onRuntimeException(final Page page, final
RuntimeException e)
{
if (e instanceof InvalidUrlException) {
//redirect to 404
} else {
return super.onRuntimeException(page, e);
}
}
Olger Warnier-2 wrote:
Sorry to keep on buggin over this, I try to understand what is the
best option to plugin the unauthorized type of exceptions into the
wicket framework.
It seems (maybe because of lack of understanding) that the
UnAuthorizedException handling can't work as it is now.
Now to move on:
I've read the RFE Alex sent.
As you create a more specific extension of the runtime exception, it
will be wrapped by the WebRequestCycleProcessor to an
InvalidURLException.
How do you make sure that it will show the 404 ? (or is that default
for the InvalidURLException ?)
It might be an idea to have some kind of exception resolvement at the
spot where this decision is made. (I don't know where that is, I have
seen hints that this is already done somehow and you are able to
override it. ) and throw runtime exceptions as is to that level. By
registering exception handler pages you have the option to customize
the behaviour.
If I like to do that in the current situation, I need to handle the
InvalidUrlException, check the cause and do something only in the
case
I'd like to process (Unauthorized)
What to do with the other causes of the InvalidUrl then ?
Kind Regards,
Olger
On 27 jul 2009, at 11:41, Alex Objelean wrote:
This is the link of the RFE:
https://issues.apache.org/jira/browse/WICKET-2307
Olger Warnier-2 wrote:
On 26 jul 2009, at 22:59, Alex Objelean wrote:
If you think this would help, then you could remove
InvalidUrlException and
invalidate the jira RFE created by me... I don't think this would
heart
anyone...
Intresting, I assume that it is of value to have this construction,
could you give me the link to the RFE ?
At any time, somehing was a WicketRuntimeException and only a
PageExpired (original or as cause) is now rethrown. All others are
wrapped.
Is there a case that in the AbstractRequestCycleProcessor the
following works then ?
else if (e instanceof AuthorizationException)
{
// are authorization exceptions always
thrown
Kind Regards,
Olger
Alex
igor.vaynberg wrote:
my point is that this case is on the fence.
it is an invalid url, and it is a security violation. so which
one
should take precendence?
my other concern is that we would have to maintain a long list of
exceptions that should be passed through, which becomes a pita.
-igor
On Sun, Jul 26, 2009 at 1:32 PM, Alex Objeleanalex_objel...@yahoo.com
wrote:
I just want to remind the reason why the InvalidUrlException was
introduced:
to avoid situations when user would tweak somehow the url and
get
the
InternalError Page... I introduced a request for enhancement
for
InvalidUrlException feature and if there are any problems
related
to it,
you
can blame me..:(
Alex Objelean
igor.vaynberg wrote:
then we are getting in a debate of what use an
invalidurlexception
really is. if we forward page expired and a bunch of other
exceptions,
why do we even need an invalidurlexception...
the point is the user has submitted a form that they should not
have
been able to, it is an invalid url...
i dont know off the top of my head what the best approach is.
-igor
On Sun, Jul 26, 2009 at 12:46 PM, Olger
Warnierol...@xs4all.nl
wrote:
Hi Igor,
if the form is disabled why is it allowed to be submitted?
In a test you can ;)
When you know what to submit, it is possible to submit those
values
without
a page, although I can imagine that it is quite hard to
achieve
due to
the
way wicket handles form variables and stuff (via the session).
Even with that in mind, I wonder if it is possible to have
the
UnauthorizedException thrown directly (without the
InvalidUrlException).
Kind Regards,
Olger
-igor
On Sun, Jul 26, 2009 at 10:58 AM, Olger
Warnierol...@xs4all.nl
wrote:
Hi Developers,
Slowly but surely I move through the tests of the wicket
security
framework.
In one test, the SecureFormTest, i ran into some strange
behaviour.
It starts with an exception like this:
org.apache.wicket.protocol.http.request.InvalidUrlException:
org.apache.wicket.authorization.UnauthorizedActionException:
Component
[MarkupContainer [Component id = form]] does not permit
action
ENABLE
(note, the test is commented in order to prevent build
failures)
There is a secureform that has no rights to be filled an
submitted.
Normal
behaviour till now was the return of a login page. In some
cases I
found
the
return of the UnauthorizedActionException - all fine till
now.
(running
1.4-rc7
Fwd: TestingAuthenticationToken and AbstractAuthenticationToken
List, in reply to the acegi sample, message was rejected to the list
(possibly due to the attachment with the sample)
Hereby the reply without the sample.
Any ideas how to share the sample ?
Hi David James,
I had the same issue, tried to get an idea on how to use acegi with
wicket.
Based on the samples , I made my own test that uses acegi for
authentication and swarm for the authorization. (http://wicketstuff.org/confluence/display/STUFFWIKI/Swarm+and+Acegi+HowTo
)
The sources are attached, containing a POM file (mvn jetty:run gives
you a working sample)
Please note that these are my test source, just to understand how
these things work.
If you are intrested in a real world example, take a look at
joiningtracks sources (repo is found here). At this moment, this web
app uses acegi without swarm for authentication, we are working on
an update that uses acegi + swarm without the test token providers
as found in the samples.
At this moment the samples (and my test) handles the authentication
based on wicket pages, creating the authentication token in code. We
changed that in our codebase, acegi handles full authentication,
creates the proper token based on the security.xml (that is part of
the spring application context).
Maybe this is helpful.
Kind Regards,
Olger
On 5 mei 2008, at 17:49, David Nedrow wrote:
Using bits of the examples provided in wicket-security, I have the
following method define in AcegiLoginContext...
private AbstractAuthenticationToken token;
public AcegiLoginContext(AbstractAuthenticationToken token) {
this.token = token;
}
Again, following the examples, I call the previous method from my
login page as follows
LoginContext ctx = AcegiLoginContext(new
TestingAuthenticationToken(username, password,
getAuthorities(username,
password)));
However, the compiler (and NetBeans) complains that
AcegiLoginContext(TestingAuthenticationToken, ...) isn't a valid
method. NetBeans suggests creating the method. But given that these
are drawn from the (presumably) working examples, what is the
issue? TestingAuthenticationToken extends
AbstractAuthenticationToken, so shouldn't it be acceptable as input
to AcegiLoginContext(AbstractAuthenticationToken token)? My brain
is so twisted around trying to find the relevant parts of the
example that I must be missing something.
I feel like Dr. Thorndyke from High Anxiety, falling into a
swirling morass of interleaved code. ;)
-David
-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
