The servlet is not handled by tapestry filter. I am not sure why, actually, as I am trying to declare it in web.xml as a workaround now. tapestry is handling all tap pages and even JSP pages for the old web site, including all security paths, but not the servlet.
Thanks for your help! On Sep 8, 2011, at 1:15 AM, Kalle Korhonen wrote: > On Wed, Sep 7, 2011 at 9:55 PM, Lenny Primak <lpri...@hope.nyc.ny.us> wrote: >> What I found out that Servlet 3.0 objects (annotated with @WebServlet and >> their derivatives) >> do not get the Shiro filter that's instantiated via tapestry-security. >> SecurityUtils.getSubject() does not work therefore. > > Hey Lenny, can you clarify what you mean by servlets "do not get the > Shiro filter"? What's the url pattern you are using for your servlet? > Are any Tapestry filters handling the request? > >> So the question becomes how do I get an instance of whatever's initialized >> by tapestry-security? >> If I have a handle on that perhaps I can put it into web.xml to work with >> the servlet 3.0 servlets, >> and by extension, Web services, REST objects, etc. > > I'm not sure I follow. @WebServlet is an alternative to declaring the > same servlet in web.xml, no? > > Kalle > > >> On Sep 2, 2011, at 12:13 AM, Lenny Primak wrote: >> >>> I think I am running into a more general problem with this. Security is >>> just not getting invoked. >>> Perhaps I have to declare shiro filter separately in web-inf? Would that >>> interfere with tap security? >>> >>> >>> On Aug 29, 2011, at 12:42 PM, Lenny Primak wrote: >>> >>>> Great! I'll try 1.2 and will do the shiro mailing list as well. >>>> I tried the @RequiresRole on a stateless Rest service, >>>> and it didn't work, I guess now I know why now :) >>>> >>>> >>>> On Aug 29, 2011, at 12:28 PM, Kalle Korhonen wrote: >>>> >>>>> Thanks Lenny. Yes, it's the wrong list but the discussion's likely >>>>> relevant to a number of other people as well. The most appropriate >>>>> list is Shiro users and incidentally, there was a discussion on the >>>>> same topic some time ago >>>>> (http://shiro-user.582556.n2.nabble.com/Using-Shiro-in-a-Web-EJB-environment-td3773528.html). >>>>> Your title says EJB container objects but mostly you seem to be >>>>> looking at securing the front-end servers. I've done stateful >>>>> (session-based) web services before and that'll work just fine using >>>>> exactly the same configuration and annotations. Stateless security >>>>> support was added/enhanced in shiro 1.2 trunk (with the release in >>>>> sight in the near future) - basically making it easier to configure >>>>> the framework (or some paths) so that each request is authenticated >>>>> and authorized separately. If you have a multi-tiered architecture >>>>> where your EJB container is running in a separate JVM, you'll have do >>>>> more integration work yourself, to maintain keys or some access tokens >>>>> to secure user requests / executions between multiple JVMs. There's no >>>>> standard way worked for it as one size rarely fits all. It's an >>>>> interesting topic nevertheless, and you should join the discussion on >>>>> Shiro users list (see http://shiro.apache.org/mailing-lists.html) to >>>>> keep up-to-date and make your opinions heard. >>>>> >>>>> Kalle >>>>> >>>>> >>>>> On Mon, Aug 29, 2011 at 8:51 AM, Lenny Primak <lpri...@hope.nyc.ny.us> >>>>> wrote: >>>>>> Hi guys, >>>>>> perhaps this is the wrong list to post this to, but >>>>>> tynamo list still doesn't work for me, and I may post this on the Shiro >>>>>> list as well. >>>>>> >>>>>> I just started using tapestry-security, and it works great! >>>>>> My application is a Tapestry front-end to a bunch of EJBs, Web services, >>>>>> and Rest objects. >>>>>> It runs in Glassfish 3.1, and J2EE 6 compliant. >>>>>> >>>>>> This application is on an intranet, and we need to secure it and put it >>>>>> out on the internet. >>>>>> >>>>>> I was wondering if/how we can use the same T-Security/Shiro >>>>>> configuration/annotation/etc. >>>>>> on the Jax-WS Web Services, and Jax-RS REST Web Services, it at all >>>>>> possible, >>>>>> with a minimum of fuss. >>>>>> >>>>>> Thanks a lot. >>>>>> >>>>>> >>>>>> --------------------------------------------------------------------- >>>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>>>> >>>>>> >>>>> >>>>> --------------------------------------------------------------------- >>>>> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >>>>> For additional commands, e-mail: users-h...@tapestry.apache.org >>>>> >>>> >>> >> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org >> For additional commands, e-mail: users-h...@tapestry.apache.org >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org > For additional commands, e-mail: users-h...@tapestry.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
