Ok, I am getting a bit more of a handle on this problem... No matter what I do, my servlet is not getting filtered by tapestry filter. I tried it all in web.xml, to no avail. Tapestry & JSP pages do work perfectly.
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
