Re: [Acegisecurity-developer] how to get online users list from acegi ????
Or does he mean to get a list of users currently on his system (i.e. with active HTTP Sessions)? If so, Matt Raible wrote a very nice UserCounterListener that did the trick nicely for me: http://raibledesigns.com/downloads/appfuse/api/org/appfuse/webapp/listener/UserCounterListener.java.html Scott Ray Krueger wrote: The user forum is at http://forum.springframework.org/forumdisplay.php?f=33 Is that what you mean? On 11/7/07, Mohammad Shamsi [EMAIL PROTECTED] wrote: hi all, i used acegi in my spring based Java EE web application. i want to access online users list, anyone know how ? please help me... Edit/Delete Message -- sincerely yours M. H. Shamsi - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] [ACEGI SECURITY 2.0]
Is Joao looking for a Roadmap document for 2.x? Scott Shi Lei wrote: I think the latest version is 1.0.5. On 10/16/07, *João Kreuzberg* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hi guys, Is there any documentation for Acegi Security 2.x, in terms of improvements/changes from current Acegi, as well as roadmap? Best Regards, -- João Kreuzberg - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Home: http://acegisecurity.org http://acegisecurity.org/ Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net mailto:Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Acegi Security with Servlet 2.3 Specification
Arturo San Feliciano Martín wrote: Hi, It´s posible to make acegi work in a application server that uses Servlet 2.3 Specification? Thanks Arturo San Feliciano Martín Yes. - This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Switching completely to Maven 2
Carlos Sanchez wrote: Hi, I'd like to remove the Maven 1 build completely because now we are half way. Samples for instance don't build with maven 2. AFAIK there's still some things that need work in Maven 2, like the docbook generation, please raise any concerns, and things that still don't work under Maven 2 so I can look into it. Is there corresponding documentation that should change (both within the project and any posted on the web site)? Scott - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] OpenSSO integration... what do you think?
Jose Luis Huertas Fernández wrote: Hi everybody, I was thinking about developing a new module to integrate Acegi with OpenSSO (https://opensso.dev.java.net/) in a similar way that the existing CAS integration. I think I have a good understanding of Acegi and I have successfully used it with CAS, X509, LDAP, Captchas, Basic, Digest, etc. . Right now I'm starting to use and understand OpenSSO. When I have a good understanding of the latter I would like to share my ideas about the integration with this list to get some feedback before starting. I would like to do a good job and contribute with it to this project, so any opinion is welcome... Thanks in advance, Jose Luis. Sounds like a good idea to me! Scott - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Releasing 1.0.2 - final 3 issues
Although not listed below, I went ahead and reverted the Siteminder filter to the 1.0.1 version so that backward compatibility could be preserved. I'll resolve SEC-319 in 1.1.0. Scott (McCrory) Ben Alex wrote: Hi everyone 23 issues are now resolved, with 3 more still outstanding. The outstanding issues are SEC-304, SEC-348 and SEC-346, assigned to Marc Antoine, Scott and Luke respectively. Would Marc Antoine, Scott and Luke please comment on these tasks, close them, or assign them to a later release (if you judge them to be non-urgent, lacking information or non-backward compatible)? We need to get 1.0.2 out so that people can benefit from the bug fixes. Thanks Ben - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Releasing 1.0.2
Carlos Sanchez wrote: I suggest copying trunk to branches/1.0.x and roll it back from there Work keeps going in trunk merging all bugfixes to 1.0.x branch as soon as they are committed. New features go to trunk only. That way we can release new features in 1.1 while still porting bugfixes to 1.0.x +1 Scott - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Releasing 1.0.2
Garvey, Paul M (GE Comm Fin) wrote: Ben, what are the Siteminder improvements? - Paul SEC-319: http://opensource.atlassian.com/projects/spring/browse/SEC-319 Scott - Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT business topics through brief surveys -- and earn cash http://www.techsay.com/default.php?page=join.phpp=sourceforgeCID=DEVDEV ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Releasing 1.0.2
Ben Alex wrote: Could other developers please finalize their 1.0.2-related tasks (see http://opensource.atlassian.com/projects/spring/secure/BrowseProject.jspa). Ben, I'd like to get the Siteminder improvements noted in SEC-319 in with the 1.0.2 release if permissible. The fix version was set for 1.1.0, but that was before the 1.0.2 and 1.0.3 releases were added to Jira. I already have changes committed in SVN that work, but I've made improvements to both the code and documentation since then that I'd like to commit and make complete. Anyone opposed? Scott - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Releasing 1.0.2
Ben Alex wrote: Hi Scott As we're now post-1.0.0, it's important that we follow the APR versioning guidelines which state that patch releases (ie 1.0.x) should be binary and source compatible with previous releases in that series. In other words, people should be able to simply drop in the new JAR and it work. Just looking at the revision history for SiteminderAuthenticationProvider and its corresponding tests, they seem to be new classes added 27 July 2006. As such, I imagine that users employing the 1.0.1 SiteMinder integration will need to change their configuration to use these new classes, and in doing so not benefit from a drop in replacement. I don't think SiteMinder usage with Acegi Security is extremely widespread, so we could relax the rules a little if there is good reason to include the SEC-319 changes in 1.0.2. The conservative choice would be to defer until 1.1.0, though (assuming I haven't misunderstood the backward compatibility issue - if the existing integration continues to work in 1.0.2, I have no problem at all with the refactoring being included so people have the choice of using it if they wish). Hi Ben, that's my thinking as well. When I saw that 1.1.0 was the only upcoming release, I assumed it would remain so and went ahead and committed changes. I should have known better that interim bug fixes and small enhancements would come about before then. SEC-319 does in fact require several changes to one's Acegi config file(s) to make work, so I'm OK with either rolling back to 1.0.0 Siteminder code for 1.0.2 or rolling forward and specifically highlighting the changes required for current Siteminder filter users. My bet is that less than a half dozen people are using it, so I don't think it would be a big issue, but I'm equally at ease with putting the 1.0.0 Siteminder code at the project's trunk/head. Please advise either way. Thanks! Scott - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] About The Following Acegi Releases
Excellent add-on points, Ray. Resonates with me too. Scott Ray Krueger wrote: Well put... Dual jars covers both camps. I spend 85% of my day in mentor mode for Spring, Hibernate, and Acegi. So your people are time poor comment really swung my vote heh. On 8/28/06, Ben Alex [EMAIL PROTECTED] wrote: Ray Krueger wrote: Ben were you suggesting having acegi-version.jar would be just binary, and acegi-version-sources.jar would be binary with source? Yes, a traditional .class-only JAR, and a combined .class plus .java JAR. People like me would use the latter, whereas people concerned about the extra 500 Kb in their download can use the former. In my experience delivering training courses, I know how very useful it is to have automatic JavaDocs and source code available to people trying to learn a new API. It is really an issue of what do we value more: * Minimizing bandwidth. Bandwidth is cheap. Every decent library (Spring, Eclipse, Java) is now dozens of megabytes to download. I won't lose much sleep adding 500 Kb (or even 1 Mb!) to a JAR download. * Maximizing productivity. Unlike bandwidth, people are expensive. People are time poor. People are constantly dealing with API changes and new APIs. People don't remember every argument and interface contract they read. We can make peoples' lives easier by including source in the JARs. Besides, we're more likely to get bugs detected and fixes contributed back if more people see the source code. Google (GWT) have obviously concluded the latter is more important, and I'm not aware of anyone objecting to their inclusion of source code. They don't even offer a source-code-free JAR, yet we would continue to. Cheers Ben - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Bean initialization, constructor injection etc.
I think your reasoning is sound...! Scott Luke Taylor wrote: I agree that reusability is important but I'm not convinced that these changes are justified on this basis, or that is just about balancing reusability and ease of use. The use of constructor arguments is about guaranteeing that objects can only be created with a specific state (the dependencies required by their design) and providing a single point for checking that state (the constructor). This is a design issue based on the requirements as determined by the developer at the time they write the class. As time goes on and different requirements become apparent from forum posts and so on, compromises are made, access is provided to state that was previously immutable or unreadable etc etc. The most reusable code may provide no-arg constructors and getters and setters for everything, but it is also the least stable. To summarise, there may be situations where we *do* want to open things up in this way for some classes, to provide extra extensibility, but I don't think accommodating the inadequacies of plexus is sufficient justification for a cross-the-board change. Could it not be argued that the changes should be made to plexus rather than Acegi? The plexus web site also says on the main page that it supports Various dependency injection techniques including constructor injection, setter injection, and private field injection. so I find that a bit confusing... Is the web site just plain wrong? Also, is plexus actually used in practice by anyone other than Maven? As I said before, we have deliberately moved towards the use of constructor injection for required dependencies, actually to avoid having to use Spring-specific constructs like the InitializingBean interface and to facilitate use outside of a Spring application context. Removing this will allow users to deploy misconfigured apps which will fail when first used rather than at deploy time, which I don't see as an improvement. What do other people think? I'm always interested in discussions about guaranteeing the state and integrity of objects and have come to see it as more of an important issue as time has passed. Luke Taylor wrote: Opening this up to the list for discussion no problem I don't think it's just a plexus problem, in general it allows extensibility and reuse. For instance you may want to subclass it with a different behaviour and the constructor arguments approach is limiting. At the end it's a matter of balancing ease of use and reusability On 7/12/06, Luke Taylor wrote: I think these kind of changes should be discussed on the list beforehand. Ben and I talked about this kind of thing a while back and agreed that enforcing initialization of objects with a particular state and being able to guarantee their integrity isn't something to be given up lightly. Do you mind if I forward your reply to the list. If we are going change this approach to accommodate plexus then it should probably be discussed there. Carlos Sanchez wrote: I'm adding Acegi to Continuum and it uses Plexus as IoC (it wasn't me) with the small problem that it doesn't accept constructor arguments. Default constructor+setters are still good to allow extension. I added javadocs to make clear the need of calling the setters later and checks to ensure the object is properly initilized. On 7/10/06, Luke Taylor wrote: What's with adding all these default constructors? There was some discussion a while back about using constructor injection for initialization where possible for required dependencies and avoiding the use of InitializingBean, setter injection etc... - Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnkkid=120709bid=263057dat=121642 ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Acegisecurity-developer Digest, Vol 2, Issue 3
One word - AppFuse: http://raibledesigns.com/wiki/Wiki.jsp?page=AppFuse
Scott
Diosmani Merino Hechavarría wrote:
I need integrate asegi, myfaces, spring and hibernate. Who can help me to do
it? I need to know what librarys I can use?
Thanks.
_
Ing. Diosmani Meriño Hechavarría
Universidad de las Ciencias Informáticas
e-mail: [EMAIL PROTECTED]
Teléfono: 837-2769
-Mensaje original-
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de [EMAIL PROTECTED]
Enviado el: Wednesday, June 07, 2006 3:05 PM
Para: acegisecurity-developer@lists.sourceforge.net
Asunto: Acegisecurity-developer Digest, Vol 2, Issue 3
Send Acegisecurity-developer mailing list submissions to
acegisecurity-developer@lists.sourceforge.net
To subscribe or unsubscribe via the World Wide Web, visit
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than Re: Contents of Acegisecurity-developer digest...
Today's Topics:
1. RequestParameters ([EMAIL PROTECTED])
2. $authz.hasPermission($contact, 16, 1) throws npe (Luo, Frank)
--
Message: 1
Date: Wed, 7 Jun 2006 09:03:23 +0200
From: [EMAIL PROTECTED]
Subject: [Acegisecurity-developer] RequestParameters
To: acegisecurity-developer@lists.sourceforge.net
Message-ID:
[EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
Hi all,
We are using a combination of acegi and spring webflow.
To start our webflow process we must use a url with a certain request
parameter in it.
For example: http://www.myHost.com/private/something?_flowId
The above URL is also a protected resource, so I get my ACEGI login
screen. I'm able to log in BUT after logging in acegi forwards
the request to http://www.myHost.com/private/something and not to
http://www.myHost.com/private/something?_flowId
Is there a way to also use the original parameters that were submitted ??
Thanks in advance ...
Best regards,
Tom.
-- next part --
An HTML attachment was scrubbed...
URL:
http://sourceforge.net/mailarchive/forum.php?forum=acegisecurity-developer/attachments/20060607/d60b4d80/attachment.html
--
Message: 2
Date: Wed, 7 Jun 2006 10:42:48 -0500
From: Luo, Frank [EMAIL PROTECTED]
Subject: [Acegisecurity-developer] $authz.hasPermission($contact, 16,
1) throws npe
To: [EMAIL PROTECTED]
Message-ID:
[EMAIL PROTECTED]
Content-Type: text/plain; charset=us-ascii
I am playing with the contact sample and try to change all jsps to
velocity.
However, I think there is a bug in
org.acegisecurity.taglibs.velocity.AuthzImpl.
A line like this throws a npe
#if( $authz.hasPermission($contact, 16,1) )
I traced the code. AuthzImpl.setAppCtx(ApplicationContext appCtx) is
never called and I couldn't figure out how to make it called from a web
app.
Hence I extended the class and made mine implements ViewTool to set
AppCtx in init(), and it worked. But should this code be incorporated
into AuthzImpl?
package sample.contact.security;
import org.acegisecurity.taglibs.velocity.AuthzImpl;
import org.apache.velocity.tools.view.context.ViewContext;
import org.apache.velocity.tools.view.tools.ViewTool;
import
org.springframework.web.context.support.WebApplicationContextUtils;
public class MyAuthzImpl
extends AuthzImpl
implements ViewTool
{
public void init( Object obj )
{
if ( !( obj instanceof ViewContext ) )
{
throw new IllegalArgumentException( Tool can only be initialized
with a ViewContext );
}
ViewContext context = ( ViewContext ) obj;
setAppCtx(
WebApplicationContextUtils.getWebApplicationContext(context.getServletCo
ntext()));
}
}
-- next part --
An HTML attachment was scrubbed...
URL:
http://sourceforge.net/mailarchive/forum.php?forum=acegisecurity-developer/attachments/20060607/4867637e/attachment.html
--
--
___
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
End of Acegisecurity-developer Digest, Vol 2, Issue 3
*
___
Home: http://acegisecurity.org
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
Re: [Acegisecurity-developer] ldap blowing up after upgrade to 1.0 final
Carlos Sanchez wrote: Sorry it wasn't spotted earlier. Perhaps we should change the Spring maven dependency back to 1.2.8 to detect this kind of thing? That's what i suggested some time ago. In fact for now only 1.2.7 is in ibiblio. Wouldn't that subsequently mean that Spring 2.x could surprise us? In more general terms, how do we maximize compatibility testing with all the major versions of Spring, the JDKs, app servers, etc.? Scott ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Final preparation for 1.0.0 final
Ben all, I don't see any items that I'd be able to tackle, so if others feel the same way, I'd suggest moving them to 1.0.1 or 1.1.0. Scott Quoting Ben Alex [EMAIL PROTECTED]: Hi everyone I would like to release 1.0.0 final on Friday 26 May. All JIRA issues assigned to me are now either completed or marked for a future release. Please note that source code reformatting with Jalopy has been completed (SEC-97) and the /jalopy.xml file revised. One of the changes included going from 80 character to 120 character word wrapping (we all have wide screens by now, right?). Committers, please re-import this file into your IDE Jalopy plugin and ensure that all source code is formatted prior to committing. There are presently eight JIRA issues outstanding for 1.0.0 final, as listed in the roadmap: http://opensource.atlassian.com/projects/spring/browse/SEC?report=com.atlassian.jira.plugin.system.project:roadmap-panel Would Luke, Scott and Marc Antoine please check these eight issues and either close them or assign them to a future release ASAP. None of them look critical except for SEC-270. A number of desired major feature improvements have been deferred to 1.0.1 or 1.1.0. These most notably include the refactored ACL services (SEC-239) and configuration simplification (SEC-271). These are two items I would have liked to see in 1.0.0, but we simply ran out of time. The sandbox contains some code for the ACL refactoring, so I'd like to invite existing ACL users to take a look and provide feedback. Cheers Ben --- All the advantages of Linux Managed Hosting--Without the Cost and Risk! Fully trained technicians. The highest number of Red Hat certifications in the hosting industry. Fanatical Support. Click to learn more http://sel.as-us.falkag.net/sel?cmd=lnkkid=107521bid=248729dat=121642 ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Preparing for 1.0.0 RC2
Paul,I don't extend SiteminderAuthenticationProcessingFilter and override the requiresAuthentication() method because every one of my protected action classes first checks to see if the user is authenticated (i.e. has an security context holder) before processing the request. I do this by calling a method in my base action class. If that base class method fails to find a security context holder, it redirects the user to j_acegi_security_check, thus invoking the Siteminder filter. This approach works very well for us, and if you'd like to try it, let me know and I'll be glad to post the code.Sorry it took a few days to respond, but please understand that continuous 16-hour days hasn't left me much room for non-essentials. It's also inefficient for me to monitor and collate all the messages on the Spring mailing list, Acegi's mailing list, Acegi's message boards and private messages, especially after I thought we already had a dialog using my work email account. Ultimately it really doesn't matter to me which venue it is, but lets try to stick to one instead of expecting all of them to be checked - I gotta sleep sometime! ;-)ScottQuoting Ben Alex [EMAIL PROTECTED]: Garvey, Paul M (GE Commercial Finance) wrote: All, Does anyone know if there is any plan to fix/investigate the Siteminder/Acegi integration issue I posted a few days ago. I made any attempt at fixing the issue but would like to know if anyone looked at it. http://forum.springframework.org/showthread.php?t=22068 http://forum.springframework.org/showthread.php?t=22067 Hi Paul Please feel free to post it to JIRA, that way it will get monitored. Best regards Ben --- 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=lnkkid=103432bid=230486dat=121642 ___ Home: http://acegisecurity.org Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] SiteMinder Integeration with spring richclient
I've never seen Siteminder used to protect client-side apps because we've always used it as a server-side ISAPI filter or Apache module. I'd recommend first checking with Siteminder to see what their solutions are for rich client apps, then once you know the mechanism of how the user's identity is passed into your app, then you can figure out what kind of adapter is necessary.Good luck!ScottQuoting Amad Fida [EMAIL PROTECTED]: All - We have spring rcp based app, which is deployed using Java Webstart. In rich client case there is method level security and not the URL filter based security. And we also have our own login dialog which we present user at startup to authenticate. I am not sure how do we use SiteMinder authentication in this setup? One possibility is to protected the jnlp link and use the Siteminder authentication filters but once authenticated how does the richclient knows about that authentication to get authorization info? Any ideas or help will he greatly appreciated. Amad - Yahoo! Photos Ring in the New Year with Photo Calendars. Add photos, events, holidays, whatever.
Re: [Acegisecurity-developer] JSF Components for Acegi
I'm not using JSF, but this sounds pretty cool, so I'll bump it for other's attention :-)ScottQuoting Cagatay Civici [EMAIL PROTECTED]: Hi, I've created custom components to bring Acegi support to the JSF Framework. I've mapped Acegi's JSP tags authorize and authentication to JSF as components. The usage is same as the jsp tags, you can find more information (download, usage etc.) on my blog at; http://www.jroller.com/page/cagataycivici Regards, Cagatay Civici,
RE: [Acegisecurity-developer] Acegi 0.8.3 to 0.9.0 errors
Oliver, You were absolutely right - it's an IBM JDK 1.3 issue. I can't post to the developer group from work right now, so could you forward this for me? I started WSAD 5.1 and its Websphere 5.0's test environment in run mode (debug disabled) and everything ran fine with 0.9.0-SNAPSHOT, but ONLY in run mode - debug mode failed with the NPE I reported earlier. I then dropped in 0.9.0-SNAPHOT-WITH-THREADLOCAL and sure enough, both the run mode and debug mode worked fine. This looks to only effect WSAD 5.x users debugging with the Websphere 5.0 Test Environment. I recommend that 0.9.0 still get released with a mention in the 0.8.0-0.9.0 upgrade doc about this and that a 0.9.0-FOR-IBM-JDK-1.3 (or whatever) be available for users still on WSAD 5.x. Thoughts? Scott Quoting Oliver Hutchison [EMAIL PROTECTED]: Looks like this you hit this: http://groups.google.com/groups?hl=delr=ie=UTF-8oe=UTF-8threadm=3F84[1] 200E.4060207%40profitsoftware.comrnum=1prev=/groups%3Fq%3D%252Binherit ablethreadlocal%2Bnullpointerexception%26ie%3DUTF-8%26oe%3DUTF-8%26hl%3D de http://groups.google.com/groups?hl=delr=ie=UTF-8oe=UTF-8threadm=3F8[2] 4200E.4060207%40profitsoftware.comrnum=1prev=/groups%3Fq%3D%252Binheri tablethreadlocal%2Bnullpointerexception%26ie%3DUTF-8%26oe%3DUTF-8%26hl%3 Dde Links: -- [1] /horde/services/go.php?url=http%3A%2F%2Fgroups.google.com%2Fgroups%3Fhl%3Dde%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26threadm%3D3F84 [2] /horde/services/go.php?url=http%3A%2F%2Fgroups.google.com%2Fgroups%3Fhl%3Dde%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26threadm%3D3F8 --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Acegi 0.8.3 to 0.9.0 errors
Quoting Ben Alex [EMAIL PROTECTED]: Ben Alex wrote: I'd prefer to avoid multiple releases floating around. We should revert back to a standard ThreadLocal and not an InheritableThreadLocal and release 0.9.0. Does anyone really require InheritableThreadLocal behaviour? I've checked in the change to use ThreadLocal. This is consistent with Spring's TransactionSynchronizationManager and AopContext (but interestingly not with LocaleContextHolder). Cheers Ben FYI I tested Acegi 0.9.0-SNAPSHOT-WITH-THREADLOCAL in our app for 4-6 hours today and all looks well. Scott --- SF.Net email is sponsored by: Tame your development challenges with Apache's Geronimo App Server. Download it for free - -and be entered to win a 42 plasma tv or your very own Sony(tm)PSP. Click here to play: http://sourceforge.net/geronimo.php ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] IMPORTANT: Project management procedures
On Mon, 25 Jul 2005 12:17:29 +1000, Ben Alex wrote
Hi everyone
Now that we've got 14 developers with CVS rights, and we've recently
introduced JIRA, I wish to propose some project management {...}
These are good and I'd recommend converting it into a new developer's guide
or orientation artifact that can be referenced on the Agegi site.
Scott
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click
___
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] FW: Sun moves its secure ID to open source
On Fri, 15 Jul 2005 07:37:54 +1000, Ben Alex wrote We should make a list of SSO implementations we want to provide pluggable interoperability for. JOSSO, CAS, OpenSSO - are there any others we can get access to that people need? I can provide help with Siteminder integration if desired. Scott --- SF.Net email is sponsored by: Discover Easy Linux Migration Strategies from IBM. Find simple to follow Roadmaps, straightforward articles, informative Webcasts and more! Get everything you need to get up to speed, fast. http://ads.osdn.com/?ad_id=7477alloc_id=16492op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Spring 1.2 Support for JDK 1.3
On Wed, 13 Jul 2005 12:49:24 +1000, Ben Alex wrote Scott McCrory wrote: In short, I'd be just a tiny voice asking for Spring 1.2+ to maintain JDK 1.3 compatability, but is it too late to decouple Acegi from Spring 1.2+? I'll move this to the Spring Developers mailing list, as it's more related to Spring than Acegi Security. Juergen posted an email in April that gave me the impression Spring's JDK 1.3 support was pretty good: http://thread.gmane.org/gmane.comp.java.springframework.devel/8208. Is this no longer the case? We would have a difficult time maintaining support for multiple Spring versions in Acegi Security. I would prefer to know that Spring 1.2 definitely could not support JDK 1.3 before going down that path. Ben, I upgraded to Spring 1.2.2 and Acegi 0.8.3 today on WSAD 5.1's Websphere 5.0 Test Environment, without significant issues. I'll continue monitoring it closely throughout the week and will let you know if I run into any show stoppers. For now at least it looks like my concerns were unfounded... Scott --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Security advisory for all Acegi Security users
On Tue, 12 Jul 2005 08:13:09 -1000, Seth Ladd wrote Luckily the security fix is available for Acegi 0.7.x. That's still compatible with Spring 1.1.x. True, but that's a stiff downgrade from 0.8.1, especially considering the filter changes. Scott --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Security advisory for all Acegi Security users
On Wed, 13 Jul 2005 08:28:18 +1000, Ben Alex wrote Just for the record, 0.8.2 was motivated as many people were happily on 0.8.1 but then Spring 1.2 came out and this broke Acegi Security 0.8.1. The majority of the community wanted 0.8.2 to be released ASAP which supports Spring 1.2. That's fair and if I were able to use a *modern* servlet container instead of Websphere 5 (pejorative intended), I'd be right beside folks asking for Spring 1.2 support, but alas Websphere 5 is my company's prefered product. I will get started on an 0.8.1.1 release to accommodate the 0.8.1 users. Thank you very much Ben! Scott does raise an interesting point in that what version of Spring are people actually using? I'd hate to think people are stuck on 0.8.1 with all the goodies (and fixes) added to 0.8.2 and now 0.9.0 and planned for 1.0.0. I really appreciate the consideration, because if history is any indication, it'll be at least 6 months after Websphere 6 is released before most existing 5.x users will be able to utilize Spring 1.2 Acegi 0.8.2+. Websphere has a solid footing in the banking and insurance industries (it's the IBM roots that do it), and that's where a heck of a lot of sophisticated J2EE is. Yes, I know this is IBM's fault for being so behind, but it is what it is. When hundreds of millions of dollars are invested in infrastructure, upgrades come more conservatively anyway. In short, I'd be just a tiny voice asking for Spring 1.2+ to maintain JDK 1.3 compatability, but is it too late to decouple Acegi from Spring 1.2+? Scott --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Spring 1.2 Support for JDK 1.3
On Wed, 13 Jul 2005 12:49:24 +1000, Ben Alex wrote Scott McCrory wrote: In short, I'd be just a tiny voice asking for Spring 1.2+ to maintain JDK 1.3 compatability, but is it too late to decouple Acegi from Spring 1.2+? I'll move this to the Spring Developers mailing list, as it's more related to Spring than Acegi Security. Juergen posted an email in April that gave me the impression Spring's JDK 1.3 support was pretty good: http://thread.gmane.org/gmane.comp.java.springframework.devel/8208. Is this no longer the case? We would have a difficult time maintaining support for multiple Spring versions in Acegi Security. I would prefer to know that Spring 1.2 definitely could not support JDK 1.3 before going down that path. I'll try to carve out time this and next week to get first-hand knowledge about what works and what doesn't with Websphere 5, Spring 1.2 and Acegi 0.8.3. I had been going mostly on forum posts and my interpretations of the docs, but your reference to Juergen's email are making me wonder... Thanks again, Scott --- This SF.Net email is sponsored by the 'Do More With Dual!' webinar happening July 14 at 8am PDT/11am EDT. We invite you to explore the latest in dual core and dual graphics technology at this free one hour event hosted by HP, AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Springframework-developer] Re: [Acegisecurity-developer] Acegi Security's ContextHolder replaced by SecurityContext
I'm not using it to this extent, but the logic sounds good to me :-) Scott On Sat, 07 May 2005 17:33:34 -0400, Colin Sampaleanu wrote Colin Sampaleanu wrote: Ben Alex wrote: Pursuant to Juergen's recommendation (http://article.gmane.org/gmane.comp.java.springframework.devel/8290), Acegi Security CVS has now had its ContextHolder and related classes removed. This functionality has been replaced by SecurityContext, which is an InheritableThreadLocal that provides a single getter/setter pair for Authentication. This is a significant change for end users, but offers a number of benefits: - Consistency with Spring core's use of a concrete ThreadLocal per functional area - SecurityContext is strictly typed (which eliminates the need for casting) - Simplified configuration as no need to specify a Context implementation for HttpSessionContextIntegrationFilter - InheritableThreadLocal used instead of ThreadLocal to simplify rich client usage (see http://forum.springframework.org/viewtopic.php?t=5004) - Elimination of handling the extra Context layer means less end user code is required Unit tests pass and I've updated the upgrade-080-090.txt in some detail. The reference guide has also been updated. It would be appreciated if developers could try the latest CVS with their applications and report any difficulties. General feedback on this change is also welcome. As I read Juergen's suggestion, I thought he was just suggesting to go away from the ContextHolder with abitlity to hold a generic Context, as it is potentially confusing as to what is going to go in there. So he suggested a SecurityContextHolder which needs to hold a SecurityContext. However, it seems to me that this simplification is much more than that, and may have gone too far, as it's all been collapsed into the one SecurityContext which is the threadlocal (effectively) and holds the Authentication. Unless I'm missing something it would still be of real use to have a real SecurityContextHolder which holds a pluggable SecurityContext. Then people can subclass that if needed to add extra data. The difference from before however is that now it is clearly security focused, and the lifecycle of the object is managed clearly by Acegi. What does everybody think? As a follow-up, from memory (it's been about a year) I believe I used a custom SecureContext to also pass along some EJB related security information (principal name, or the ejb run-as user) between different layers along with the Acegi specific info. The app in question was a mixed EJB and Spring app, using the EJB version of OSWorkflow. In general, I think if by default the user does not have to specify the actual SecurityContext implementation class unless they want to override it, and the SecurityContextHolder ensures there is always a SecureContext (throwing an exception if it's set to null), then even with the separate SecurityContextContextHolder and SecurityContextContext, it's still way less verbose than the old classes, and just about as convenient to use as with the completely collapsed version, i.e.SecurityContextHolder.getSecurityContext() .getAuthentication(); This essentially allows users to associate any information that logically belongs with the current security context with the context, and it is clear that the lifecycle of the security context is managed by Acegi Security, unlike the old classes. Ben has pointed out that you can always use a custom UserDetails implementation. This is true, but implicates AuthenticationDao and the UserDetails impl. where they shouldn't necessarilly be implicated. Colin -- Colin Sampaleanu Interface21 Principal Consultant Spring Training, Consulting and Support - From the Source http://www.springframework.com --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/? r=20 ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer --- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list
Re: [Acegisecurity-developer] Re: [Springframework-developer] Spring 1.2 RC2 and Acegi Security
On Wed, 20 Apr 2005 23:19:05 +1000, Ben Alex wrote In terms of your other email's suggestion to use a SecurityContext ThreadLocal instead of ContextHolder, I've given this some more thought and we can do this and still offer a clean migration path for 99% of existing ContextHolder users. Whilst I know some people (myself included) have found ContextHolder's general-purpose approach useful, it seems more important overall to achieve standardization with Spring Core in the ThreadLocal approach, and as such it seems worthwhile refactoring to SecurityContext. I think the nomenclature of SecurityContext does make more sense, but then again I don't need the general approach of ContextHolder. Just my 2c. Scott --- This SF.Net email is sponsored by: New Crystal Reports XI. Version 11 adds new functionality designed to reduce time involved in creating, integrating, and deploying reporting solutions. Free runtime info, new features, or free trial, at: http://www.businessobjects.com/devxi/728 ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] JIRA
On Mon, 28 Feb 2005 21:56:34 -0500, Dmitriy Kopylenko wrote Ben, so what's the story with Spring subproject? +999 :-) --- SF email is sponsored by - The IT Product Guide Read honest candid reviews on hundreds of IT Products from real users. Discover which products truly live up to the hype. Start reading now. http://ads.osdn.com/?ad_id=6595alloc_id=14396op=click ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Re: [Springframework-developer] Roadmap towards Aceg Security official 1.0.0 release
On Thu, 30 Dec 2004 15:13:18 -0500, Matt Raible wrote Finally, the status of the project is up for discussion. I met Rod a few days back and we briefly discussed making Acegi Security a formal Spring subproject. This, coupled with a 1.0.0+ version number, would make some people and organisations more comfortable using it. What does the community think of this idea? +1 Matt I forgot my +1 on this as well. Scott --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Roadmap towards Aceg Security official 1.0.0 release
Ben, Excellent, sounds like a well thought-out plan towards 1.0. I'd recommend an in-between approach for the container adapters. I agree that including lightly-used, non-portable modules in the main distribution can lead to expectations that they be maintained as fully as the core. However, there is potentially a lot of value in having them available with documentation and samples, and you never know which of them may become heavily used over the next year. As you already know, app security is a big problem space that Acegi helps a lot with, but everyone historically has taken different approaches to the problem so there's a lot to think through when incorporating Acegi into their project (add to that Spring IoC/DI - something new to most developers). The good thing is that container adapters, documentation and samples can help a lot with the initial learning curve since it helps the developer get a working prototype up and running faster in the environment they need to operate in, and I'd posit that there will be a handful of popular ones to boil out over 2005, probably including Siteminder (but that may just be my own environment talking). So what's a middle-ground? Perhaps keep them in the same project, but distribute them out into separate, optional JARs, a la Hibernate-Tools and document them in addendums of the main reference, and then clarify that these are platform-dependant without official owners, so they aren't considered part of the core product. Not a bad idea to try to pin an owner on each one nonetheless... Just thinking out loud - take or discard as you wish...! Scott On Thu, 30 Dec 2004 12:53:04 +1100, Ben Alex wrote Version 0.7.0 introduces the final features that I believe are necessary for a broadly useful enterprise application security framework. I believe most of the code could now be considered mature, except for the newer domain object instance security capabilities. Whilst these new capabilities have only existed for between two and four months, they're potentially HIGHLY useful, well-documented, fully unit tested, and demonstrated in the Contacts sample application. I also know of several real applications where they're being used, so I expect the API to remain fairly stable. By releasing Version 0.7.0 I hope to see the domain object instance security achieve more widespread use, so there can be appropriate confidence in a 1.0.0 release. To a lesser extent it is also intended to test the various new minor features added to CVS over the past few months, along with the Mavenised build system. I do not intend to add any new major features prior to a 1.0.0 release. There are several potentially useful areas, but none are critical for most applications and the architecture enables them to be added very easily and safely: * Remember-me functionality. There has been some design ideas put forward, but just not implemented. * Anonymous user functionality. This should be similar to any remember-me approach. People have already implemented solutions to this requirement (see forums). * Maintained and unit tested LDAP provider. There is something in the sandbox and contributions on the forums, but we need tests to add any to core. * Wider support for remoting protocol automatic security propagation. We already offer RMI and HttpInvoker, which covers most Spring Rich users. * Database- sourced ObjectDefinitionSources. Spring itself will be offering database-driven configuration (see sandbox). * Java 5 annotation support. I am waiting to see what happens with Spring core's attributes abstraction, and then use whatever approach follows. * AspectWerks support for domain object instance security. It's easy to do this, but I'd like a similar model to AspectJ where Spring DIs the advice. One issue I'd appreciate some comments on is container adapter deprecation. I know some people use the JBoss container adapter (as they need to use EJB security as well), but I've not heard of any usage of the Resin, Tomcat or Jetty adapters. It seems unwise to maintain a suboptimal (non-portable) approach, especially as pre- 1.0.0 we can deprecate them. Finally, the status of the project is up for discussion. I met Rod a few days back and we briefly discussed making Acegi Security a formal Spring subproject. This, coupled with a 1.0.0+ version number, would make some people and organisations more comfortable using it. What does the community think of this idea? Best regards Ben --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list
Re: [Acegisecurity-developer] Preparing for 0.7.0
Ben, Just curious - what's your approach towards an eventual 1.0 release? I ask because technical managers, architecture review boards, etc. can misinterpret sub-1.0 versions as unstable, whereas even Acegi 0.6 most certainly is not! Thanks in advance, Scott --- The SF.Net email is sponsored by: Beat the post-holiday blues Get a FREE limited edition SourceForge.net t-shirt from ThinkGeek. It's fun and FREE -- well, almosthttp://www.thinkgeek.com/sfshirt ___ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
RE: [Acegisecurity-developer] Release 0.61
On Thu, 23 Sep 2004 22:57:38 -0700, March, Andres wrote +1 for Apache guidelines And +1 for a 1.0 release after a maven build is implemented +1 to what he said :-) . Scott --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
Re: [Acegisecurity-developer] Instance security
On Fri, 24 Sep 2004 13:53:12 +0100, App Fuse mailing list wrote hi all, I'm just starting to learn about acegisecurity. I've been looking at the archive and was just wondering what the current status of: Instance security in .61 Documentation on the above. Example applications/code using above. Since instance security is specific to the objects you're protecting and the kinds of checks you do inside of (or right above) your service methods, ultimately you'll have to write this yourself. That said, the underlying support is there, although the docs don't cover it much (I'll be glad to help in that regard). Maybe if I share how I'm approaching the problem you can glean something from it. Note that I've only implemented 25% of the ideas below, so if you or anyone sees a better way, please let me know. ;-) My application's security can be organized as protecting 3 things - 1) the visibility of GUI elements like links, buttons, columns, tabs, 2) the visibility of database records and 3) the access to my service methods. I'll protect #1 using the authz JSP tag and mapping role sets to visual elements (I still like the term entitlements better, but that's just me). I'll protect #2 by including the user's identity in formulating DB queries, and I'll protect the service methods by including declarative security and those same roles mentioned above, as well a programmatically using the user's identity and the object's identity to determine if they can update or delete the thing. This could be done inside of the service methods themselves, but I'm leaning towards putting these checks in a service facade just above to keep the services clean. The best example I've seen on this is (although embedded in the service code) the ContactManagerFacade.java code in Acegi's samples. Take a look at the getById(int) method for more info. HTH, Scott --- This SF.Net email is sponsored by: YOU BE THE JUDGE. Be one of 170 Project Admins to receive an Apple iPod Mini FREE for your judgement on who ports your project to Linux PPC the best. Sponsored by IBM. Deadline: Sept. 24. Go here: http://sf.net/ppc_contest.php ___ Acegisecurity-developer mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
