Hi,
as a late follow-up, we ended up being like this:
@ValidationMethod
public void validateOnResolution( final ValidationErrors errors ) {
rest().validateFor( GET, new Runnable() {
/** {@inheritDoc} */
@Override public void run() {
if(
Supporting Apache Shiro (which I highly recommend; it’s really good) in any
Stripes app is pretty easy:
http://www.ecyrd.com/ButtUgly/wiki/Main_blogentry_100910_1
You can then e.g. have your own Interceptor or actionbean superclass which does
Subject.login() based on e.g. OAuth headers or
Joaquin,
Since there are so many different ways people do
authentication/authorization, I didn't build any kind of authentication
into it for those reasons.
I've personally done it a couple of different ways using this REST
framework. One was BASIC auth and another way was actually writing an
Thanks Rick! Off topic a bit, but how are login credentials handled with this
framework when calling a rest method?
Thanks
Joaquin
On Feb 28, 2015, at 7:13 AM, Rick Grashel rgras...@gmail.com wrote:
Hi guys,
I also had similar issues writing REST services with Stripes. I
One option could be Standard Servlet security offers Basic auth, SSL and
other goodies. Configure your web.xml pointing to an actionbean url
El mar 2, 2015 4:38 PM, Joaquin Valdez joaquinfval...@gmail.com
escribió:
Thanks Rick! Off topic a bit, but how are login credentials handled with
this
Hi,
we've been in the same situation, and we've used the same double approach
described by Remi: facing public, CMS-heavy sites using REST-like services
provided by Stripes, whereas transactional applications are invoking CMS's
services via its REST services.
The only downside with this approach
We’ve just been lazy and done
public Resolution foo()
{
switch( getContext().getRequest().getMethod() )
{
case “post”:
return doPost();
case “get”
return doGet()
case “delete”:
return doDelete();
Hi guys,
I also had similar issues writing REST services with Stripes. I absolutely
did not want to get rid of Stripes, so I had to write a REST ActionBean
framework for Stripes which supported all of Stripes validation and
binding. If you are interested, you can download it here:
Absolutely, there are many ways to implement pure HTTP backends with
Stripes. The verbs are not mandatory, you can stick to GET and POST it
works just fine. I never understood why everyone went that crazy with PUT
and DELETE. I think that Stripes shines at HTTP services implementation
(binding
Btw, I've done something similar on a small app : we allow the site owner
to change some of the pages using MCE or something. We also allow to upload
images and reference them in those pages.
It does the job for us and for what it's cost, didn't take long to hack.
But it's pretty ugly, and we
Hi,
We have been using Stripes for the last 5 years and love the framework. The
sites we have used it on are all transactional (think CRM) with back-end
integration to other systems for customer profile management, account
management etc.
We also have a fairly static public facing web site using
Hi,
Interesting question :)
I guess a fundamental indicator is the complexity of the CMS vs your own
code. I mean, will the public facing website include only a small part of
customization (a few new forms here and there, a few pages...) and most of
the hits will be actually handled by the CMS ?
12 matches
Mail list logo
