Apache Shiro Integration

[methodfoo]

Saw two threads on this topic earlier from a few months ago but
haven't seen any statements from the committers.

We're considering Play and already use and love Shiro. Since Shiro
doesn't require servlets and could provide Play applications awesome
security out of the box, is there any intent to integrate it into the
framework? It would be sooooo sweet.

An answer one way or the other would be extremely helpful so we can
plan.

Thanks,

[Erwan Loisant]

Hi,

There is no plan to integrate Shiro. That said, if as you say it
doesn't depend on the servlet API, you can probably include it in your
Play project.

As far as I'm concerned I wouldn't do it tho, I've looked at the doc
and it seems like there is server-side sessions. By using it looks
like you're going to lose one of the key feature of Play,
statelessness.

> --
> You received this message because you are subscribed to the Google Groups "play-framework" group.
> To post to this group, send email to play-fr...@googlegroups.com.
> To unsubscribe from this group, send email to play-framewor...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/play-framework?hl=en.
>
>

--
Erwan Loisant

[Les]

Hi there,

Erwan, as you've never used Shiro before, I think it a bit
presumptuous to recommend against using it based on your assumption.
With respect, your assumption is incorrect:

Shiro _supports_ server side sessions in any environment (web or not),
but they are not required - the Session Management mechanisms and
sessions are only ever 'triggered' if some code calls
shiroSubject.getSession(); If you don't make that call, a session
does not need to be created. And even if sessions were used, they
don't require server-side state - they can be stored in the client
tier if required. You can create your own SessionDAO to determine
exactly how session state is stored (client tier or server tier).

So, again, Shiro doesn't require sessions. It will work perfectly
fine in Play or any other stateless framework. It does not require
the Servlet API, but will leverage it in Servlet environments.

Regards,

Les Hazlewood
Apache Shiro team

P.S. As an architect who has been responsible for very large websites
(think millions of users), there is nothing wrong with server-side
state *if it is managed appropriately*. Enterprise caches (Memcache,
Coherence, Ehcache+Terracotta, etc) are an excellent option for
maintaining server state, and have been used with great success (Shiro
plugs in to these for sessions if you want to use them). 100%
statelessness is nice, but often not achievable in the real world -
the application teams should decide what they need and act accordingly
rather than hold on to an ideal tenet that may not be achievable or
even necessary.

[Nicolas]

Interesting, it would be actually quite interesting to have a Shiro module I think...

[Olivier Refalo]

About your PS:

The beauty of IT is that, unlike health, you can fix everything with cash. So if session scalability comes at the cost of a $10.000/cpu software or a bunch of new hardware boxes to handle the load, then you may be right. But you won't walk away with simplicity.

As an Enterprise Architect myself, I think you are missing the point about statelessness, it's not only about scalability.. it's about speed of development.

[Erwan Loisant]

Hi,

On Thu, Jan 13, 2011 at 19:55, Les <lhazl...@gmail.com> wrote:
> So, again, Shiro doesn't require sessions.  It will work perfectly
> fine in Play or any other stateless framework.  It does not require
> the Servlet API, but will leverage it in Servlet environments.

Well, that's good to hear that Shiro doesn't force you to create
sessions. That said you could perfectly have sessions in Play, it's
just that they are not provided by default and it's not recommended to
have any.

Also kudos for the independence to the servlet API, too many Java
libraries depends on it when they don't need to.

> P.S. As an architect who has been responsible for very large websites
> (think millions of users), there is nothing wrong with server-side
> state *if it is managed appropriately*.  Enterprise caches (Memcache,
> Coherence, Ehcache+Terracotta, etc) are an excellent option for
> maintaining server state, and have been used with great success (Shiro
> plugs in to these for sessions if you want to use them).  100%
> statelessness is nice, but often not achievable in the real world -
> the application teams should decide what they need and act accordingly
> rather than hold on to an ideal tenet that may not be achievable or
> even necessary.

I have yet to see a real world application that can't be implemented
without server-side sessions (and don't talk about a shopping carts).
On the other hand the benefits of stateless is very clear to me. Even
if you manage your sessions correctly, you still have a bunch of
problems to solve you wouldn't have in a stateless app.

And BTW, there's no such thing as 99% stateless: your app is either
stateless or it's not. The one percent stateful means that you need to
keep data in memory for sessions, you need to have some kind of
synchronization between your fronts (or ensure a given user always get
to the same server)...

--
Erwan Loisant

[Marcus Downing]

So is anybody working on this? We like the look of Shiro, but don't have the time or familiarity to develop a module for it.