Comments against Restlet 1.2M2
Hi all, First of all, I love the RepresentationInfo. :) Thanks for adding this. :) Some comments against that release: - I wonder how to create a RepresentationInfo since it is abstract; for the time being I created my own RepresentationInfo class derived from the abstract class. - Wouldn't it make sense to add a constructor RepresentationInfo(Variant variant, Date modificationDate) This constructor would add all information available from the variant (i.e. MediaType, Language etc.) to the RepresentationInfo plus the modification time. - Previously I used Resource(Context, Request, Response) in my derived Resource classes. This constructor is not available anymore in ServerResource. Not a big problem, though, even I have had to make my properties non-final, which is also not a big problem since Resources are not meant to be thread-safe. - Related to the above mentioned point, I allowed that my derived Resources throw an exception in the constructor. This was very convenient since Restlet automatically issued an error status. While moving my initialisation stuff to the ServerResource.init() method I recognised that init() does not allow to throw an exception, so I have to wrap my initialisation code in a try / catch block. I wonder if UniformResource#init() shouldn't be changed to protected void init() throws ResourceException; (or maybe Exception instead of ResourceException?) If an exception was thrown, Restlet 1.2 could handle it like Restlet 1.1 handled exceptions thrown by the constructor. Best regards, Lars -- http://www.semagia.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1518119
Re: Restlet 1.2 M2 released
Really need that full annotation syntax working to test it out ;0) Regarding that, it does seem odd to have @Get(xml) but use MediaType.TEXT_XML in the code. @Get(TEXT_XML) ? Shame you can't have @Get(MediaType.TEXT_HTML). I don't know. Jerome Louvel wrote: Hi Jonathan, We would be quite happy to get your feed-back, positive or not :) Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Jonathan Hall [mailto:jonrh...@gmail.com] Envoyé : mercredi 1 avril 2009 18:08 À : discuss@restlet.tigris.org Objet : Re: Restlet 1.2 M2 released Excellent! I'm looking forward to seeing if the new Resource API simplifies development. Jerome Louvel wrote: Hi all, The second 1.2 milestone is out! A complete coverage is available in our blog: http://blog.noelios.com/2009/04/01/restlet-12-m2-released/ http://blog.noelios.com/2009/01/23/restlet-12-m2-released/ Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org http://www.restlet.org/ Noelios Technologies ~ Co-founder ~ http://www.noelios.com http://www.noelios.com/ -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=15083 71 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1508861 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1520632
Re: Restlet 1.2 M2 released
Jonathan Hall schrieb: Shame you can't have @Get(MediaType.TEXT_HTML). I don't know. Would it work to change MediaType from class to an enum? That could work, but I'm not sure best regard Stephan -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1520761
Re: Restlet 1.2 M2 released [throw previous email away]
Stephan Koops schrieb: Jonathan Hall schrieb: Shame you can't have @Get(MediaType.TEXT_HTML). I don't know. Would it work to change MediaType from class to an enum? That could work, but I'm not sure While sending the email I remembered: You can't add new MediaTypes this way, so we could forget my previous idea. best regards Stephan -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1520779
Re: Restlet 1.2 M2 released
On Apr 2, 2009, at 11:11 AM, Stephan Koops wrote: Jonathan Hall schrieb: Shame you can't have @Get(MediaType.TEXT_HTML). I don't know. Would it work to change MediaType from class to an enum? That could work, but I'm not sure This would sacrifice the ability to create new MediaTypes in applications which use the framework. Rhett -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1520788
Re: Restlet 1.2 M2 released [throw previous email away]
An alternative would be to have a MimeType class which had String constant values for all the common MediaTypes, then you would only need to use strings if you had a non common media type. One other thing I've noticed that in some places the mime type is shortened (e.g. xml instead of text/xml). Is it possible to use the full mime type across the API if required? Paul On Thu, Apr 2, 2009 at 9:13 AM, Stephan Koops stephan.ko...@web.de wrote: Stephan Koops schrieb: Jonathan Hall schrieb: Shame you can't have @Get(MediaType.TEXT_HTML). I don't know. Would it work to change MediaType from class to an enum? That could work, but I'm not sure While sending the email I remembered: You can't add new MediaTypes this way, so we could forget my previous idea. best regards Stephan -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1520779 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1520903
Re: Restlet 1.2 M2 released
On Thu, Apr 2, 2009 at 12:13 PM, Rhett Sutphin rh...@detailedbalance.netwrote:
On Apr 2, 2009, at 11:11 AM, Stephan Koops wrote:
Jonathan Hall schrieb:
Shame you can't have @Get(MediaType.TEXT_HTML). I don't know.
Would it work to change MediaType from class to an enum? That could work,
but I'm not sure
This would sacrifice the ability to create new MediaTypes in applications
which use the framework.
I proposed using Class? extends MediaType as the annotation parameter
type, but Jerome said (in
http://n2.nabble.com/New-resource-API-design-tt2348626.html#a2400409):
I like your idea of using more formal annotation parameters, but using
MediaType subclasses seems overkill. I wish we could pass MediaType instances
like we already have defined as annotation parameters...
Also, in addition to a media type, a variant can also be composed of a
character set, a list of encodings and even a list of languages, that would
result in a rather verbose annotation.
A lot of the time, the standard metadata constants provided by Restlet are
all you need, so what about allowing both enums for standard metadata and a
way of specifying custom metadata that is more verbose but also
type-safe? There's a way to do this that still allows simple (but unsafe)
string metadata. It would let you say things like:
@Get(media=APPLICATION_ALL_XML)
@Get(charsets={US_ASCII, ISO_8859_1})
@Get(userMedia=MyCustomMediaType.class)
in addition to the string forms. Here's a code sketch:
enum StdMediaType {
DEFAULT(MediaType.ALL),
ALL(MediaType.ALL),
APPLICATION_ALL(MediaType.APPLICATION_ALL),
APPLICATION_ALL_XML(MediaType.APPLICATION_ALL_XML),
// etc.
;
public boolean isDefault() { return this == DEFAULT; }
public MediaType mediaType() { return mediaType; }
StdMediaType(MediaType mediaType) { this.mediaType = mediaType; }
private final MediaType mediaType;
}
enum StdCharacterSet {
DEFAULT(CharacterSet.DEFAULT),
ALL(CharacterSet.ALL),
ISO_8859_1(CharacterSet.ISO_8859_1),
US_ASCII(CharacterSet.US_ASCII),
// etc.
;
public boolean isDefault() { return this == DEFAULT; }
public CharacterSet mediaType() { return mediaType; }
StdCharacterSet(CharacterSet mediaType) { this.mediaType = mediaType; }
private final CharacterSet mediaType;
}
enum StdEncoding { /* similarly */ }
enum StdLanguage { /* similarly */ }
@Documented
@Retention(RetentionPolicy.RUNTIME)
@Target(ElementType.METHOD)
public @interface Get {
/**
* Representable media types specified either via extension names or
full
* MIME type.
*/
String[] value() default */*;
/**
* Representable standard media types.
*/
StdMediaType[] media() default StdMediaType.DEFAULT;
/**
* Representable user (nonstandard) media types, specified by custom
subclass of MediaType.
*/
Class? extends MediaType[] userMedia() default {};
/**
* Representable standard character sets.
*/
StdCharacterSet[] charsets() default StdCharacterSet.DEFAULT;
/**
* Representable user (nonstandard) media types, specified by custom
subclass of CharacterSet.
*/
Class? extends CharacterSet[] userCharsets() default {};
// Similarly for encodings, languages
}
--tim
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1521391
list of resource with relatives url
Hi i'm an italian student and i have to plan a restful architecture using RESTLET. The architecture have to implement a B2B message exchange in xml format powered by GS1 XML. -My problem is to understand how makes the client thet have to get or post a resource to know resource's location and therefore the final url to use in the GET or POST HTTP messages to refer to the correct locations. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1516595
Re: Java 6
A more general note: Applications compiled with Java 5 typically run on Java 6 JVMs without problems. Applications compiled with Java 6 don't run on Java 5 JVMs- the Java 5 JVM detects that the bytecode version is higher and therefore rejects it. So, in theory, you don't need a Java 6 build of Restlet. Which JVM are you running on? On 31 Mar 2009, at 17:57, Cliff Binstock wrote: Is it correct that the current build is based on Java 1.5? Is there a Java 6 build available? Or do I have to build this myself? Notably, I can’t run a Java 6 compiled application under tomcat w/ Java 6. I’m not 100% certain, but it appears that this is because Restlet itself is 1.5 (I get class version errors loading the restlet application). Thanks much, Cliff Binstock Coyote Reporting -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1522246
Re: list of resource with relatives url
Do you mean, how can a client know what URIs to use when performing service operations? It really doesn't have anything to do with Restlet in particular, and I could be wrong here, but I think this is a still-evolving aspect of REST. For a while, WADL seemed to be gaining some momentum, but there are some arguments against using it, the most notable of which is that we don't really want to repeat the mistakes of WSDL (the give me a WSDL and I'll auto-generate my client code mentality goes against some of the basic principles of REST, primarily flexibility but probably other stuff too). If you google around on WADL, you'll see what people have to say. The key, though, is that once you know where to start (a base URI to use when beginning your operations), a system that obeys REST correctly will make it easy for a client to operate after that. For example, let's say you have a generic object factory kind of resource, at https://server/app/object. That's all your client should need to know to get started. You'll POST to this resource, to create a new resource (owing to REST's adherence to the HTTP verbs, you know what to use to do create operations without any further guidance). If it succeeds, a 200 OK response comes back, along with the location of your new object in the header of the response. The client can pull the URI of the new object back (e.g. https://server/app/object/12), and do new operations with it - GET to see it, PUT to update it, DELETE to get rid of it. I guess this is a long way to say I don't know, but I also think that in a proper REST design, it probably doesn't much matter. :) In my opinion, you can either codify the endpoints formally, as in a WADL, or you can informally simply agree on your starting point URIs, code them into your clients, and go from there. On Thu, Apr 2, 2009 at 5:35 AM, webp...@tigris.org wrote: Hi i'm an italian student and i have to plan a restful architecture using RESTLET. The architecture have to implement a B2B message exchange in xml format powered by GS1 XML. -My problem is to understand how makes the client thet have to get or post a resource to know resource's location and therefore the final url to use in the GET or POST HTTP messages to refer to the correct locations. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1516595 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1522395
Re: Comments against Restlet 1.2M2
I also ran in to the issue of having a constructor that would throw a ResourceException if the request was bad in some way, and now the init() method doesn't declare any exceptions. Seems pretty reasonable to just add this. One other alternative would be to change ResourceException to be a RuntimeException subclass. This would allow any ServerResource annotated method to throw this exception without declaring it explicitly... -Dave Fogel On Thu, Apr 2, 2009 at 7:58 AM, Lars Heuer he...@semagia.com wrote: Hi all, First of all, I love the RepresentationInfo. :) Thanks for adding this. :) Some comments against that release: - I wonder how to create a RepresentationInfo since it is abstract; for the time being I created my own RepresentationInfo class derived from the abstract class. - Wouldn't it make sense to add a constructor RepresentationInfo(Variant variant, Date modificationDate) This constructor would add all information available from the variant (i.e. MediaType, Language etc.) to the RepresentationInfo plus the modification time. - Previously I used Resource(Context, Request, Response) in my derived Resource classes. This constructor is not available anymore in ServerResource. Not a big problem, though, even I have had to make my properties non-final, which is also not a big problem since Resources are not meant to be thread-safe. - Related to the above mentioned point, I allowed that my derived Resources throw an exception in the constructor. This was very convenient since Restlet automatically issued an error status. While moving my initialisation stuff to the ServerResource.init() method I recognised that init() does not allow to throw an exception, so I have to wrap my initialisation code in a try / catch block. I wonder if UniformResource#init() shouldn't be changed to protected void init() throws ResourceException; (or maybe Exception instead of ResourceException?) If an exception was thrown, Restlet 1.2 could handle it like Restlet 1.1 handled exceptions thrown by the constructor. Best regards, Lars -- http://www.semagia.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1518119 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1522423
RE: Re: Restlet Jax-RS extension and OSGi
Dave,
Were you able to fix or workaround this issue? If not, you should enter a
defect report (a patch would be nice).
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : David Fogel [mailto:carrotsa...@gmail.com]
Envoyé : vendredi 20 mars 2009 04:55
À : discuss@restlet.tigris.org
Objet : Re: Re: Restlet Jax-RS extension and OSGi
Hi Stephan-
I've been experimenting with the restlet.ext.jaxrs support, trying to get a
small test project working, and I've run into what seems like a pretty big
problem. While I am fairly new to JAX-RS, it is my understanding that the
suggested way of giving your Resource classes access to other things in
their environment (such as a persistence service, a ServletContext, an osgi
BundleContext, etc) is by creating classes that extend
javax.ws.rs.ext.ContextResolver, annotating them with @Provider, and
registering instances of them with the jax-rs implementation. The container
should then be able to inject these custom objects into Resource classes
that annotate a parameter or field type with @Context.
For example, if I have a service class called StorageService, I would create
a ContextResolver like this:
@Provider
public class StorageServiceResolver extends ContextResolverStorageService
{
private StorageService service;
public StorageServiceResolver(StorageService service) {
this.service = service;
}
public StorageService getContext(Class? type) {
return service;
}
}
I would then be able to access the StorageService object within my Resource
classes like this:
@Path(path/to/root/resource)
public class MyResource {
// should be able to do annotate a field:
@Context
private StorageService service;
// OR should be able to annotate a constructor param:
public MyResource(@Context StorageService service) {
this.service = service;
}
@GET
@Produces(text/plain)
public String getStoredThing(@QueryParam(id) String id) {
// and then access the service here:
return service.getValueForID(id);
}
}
But when I create such classes, and register them with your JaxRsRestlet,
the JaxRsRestlet refuses to accept the Resource classes, claiming that they
are missing any valid constructor or that a field can not be injected with
that type.
The problem may be that the methods in WrapperUtil.java don't make use of
the current set of providers, but instead expect only the minimal set of
predefined context types.
Is there some other way I'm missing to give my Resource classes access to my
application environment?
thanks,
-Dave Fogel
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=13610
04
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1522529
Re: Restlet 1.2 M2 released [throw previous email away]
The MetadataService is what you're talking about. It translates between strings and other useful dimensions (in this case, MediaType instances). Right now, though, it only supports "extensions" as the strings, which mean to be filename extensions. So that's why we have "txt" as the shorthand for MediaType.TEXT_PLAIN. It seems a good idea to me to change MetadataService to support other kinds of shortcuts. In fact, as others have pointed out, it should be desirable to have the actual full MIME type as a shortcut. -Tal Paul Austin wrote: An alternative would be to have a MimeType class which had String constant values for all the common MediaTypes, then you would only need to use strings if you had a non common media type. One other thing I've noticed that in some places the mime type is shortened (e.g. xml instead of text/xml). Is it possible to use the full mime type across the API if required? Paul On Thu, Apr 2, 2009 at 9:13 AM, Stephan Koops stephan.ko...@web.de wrote: Stephan Koops schrieb: Jonathan Hall schrieb: Shame you can't have @Get(MediaType.TEXT_HTML). I don't know. Would it work to change MediaType from class to an enum? That could work, but I'm not sure While sending the email I remembered: You can't add new MediaTypes this way, so we could forget my previous idea. best regards Stephan -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1520779
Re: list of resource with relatives url
Excellent summary, Stephen! Requiring a descriptor (in any format) to find a service URI often just moves the problem -- making the next question what is the best URI to publish the descriptor? Still, it's needful to describe REST APIs, and this often seems unreasonably hard to do. For me, anyway. Someday I'd like to attack a Restlet-specific application descriptor mechanism that is both machine and human readable ... sort of an extended Javadoc for Restlet ... I think the Resource refactoring might be one key to doing this. Ideally the descriptor would work two ways -- you could export it from a Restlet server application, and then feed it to a code generator to make a Restlet client skeleton. We'd also need some way of interrogating the plumbing of an application -- what patterns reach what targets. Anyway, fun to think about. - Rob On Thu, Apr 2, 2009 at 2:26 PM, Stephen Groucutt stephen.grouc...@gmail.com wrote: I guess this is a long way to say I don't know, but I also think that in a proper REST design, it probably doesn't much matter. :) In my opinion, you can either codify the endpoints formally, as in a WADL, or you can informally simply agree on your starting point URIs, code them into your clients, and go from there. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1522571
RE: Principal from HttpServletRequest
Hi Paul, I've just added support for this by copying the Servlet's UserPrincipal into the Request#clientInfo#subject#principals property. Could you do some testing with latest trunk or next snapshot and let me know if it works fine? Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org/ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com/ http://www.noelios.com _ De : Paul Austin [mailto:mail-li...@revolsys.com] Envoyé : vendredi 20 mars 2009 20:55 À : discuss@restlet.tigris.org Objet : Principal from HttpServletRequest Is it possible to get the Princpal object from the HttpServletRequest without getting access to the HttpServletRequest itself. I'm using spring security as my authentication layer which sets a Principal in a wrapper of the request. Cheers, Paul -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1523141
RE: X509 certificate authentication
Hi there, We have some pointer in this RFE: Support end-to-end representation security http://restlet.tigris.org/issues/show_bug.cgi?id=270 Definitely an area of contribution! Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : webp...@tigris.org [mailto:webp...@tigris.org] Envoyé : lundi 23 mars 2009 18:33 À : discuss@restlet.tigris.org Objet : X509 certificate authentication Hi All I'm prototyping an application which will use user and server certificates extensively: every client request and server response must be ciphered and digitally signed. The ciphered part is easy with https, but ¿how do I accomplish the second part? I'm a bit confused and I think of XML-DSIG but then better using a SOAP approach. Is there a more restful approach? Ideally, the server side will be a REST application, and clients build with Eclipse RCP as OSGI bundles. Thanks -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=13910 51 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1523201
RE: Using credentials from the Container
Hi Dustin, I've just added a change to SVN trunk for Paul Davis that copies the Servlet's UserPrincipal into the Request's clientInfo#subject property. With that information, you could add matching Restlet's UserPrincipal/RolePrincipal(s) and leverage the rest of the security API. Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : Dustin N. Jenkins [mailto:dustin.jenk...@nrc-cnrc.gc.ca] Envoyé : mardi 24 mars 2009 21:01 À : discuss@restlet.tigris.org Objet : Using credentials from the Container Hi everyone, Can someone tell me, with the new Security API, will it be possible to use the credentials from the Container? I use the BASIC authentication with Tomcat now, but I'm wondering if it's possible to have the Restlet Request's ChallengeResponse be populated automagically from the Container's principal information. Thanks! Dustin -- Dustin N. Jenkins | Tel/Tél: 250.363.3101 | dustin.jenk...@nrc-cnrc.gc.ca facsimile/télécopieur: (250) 363-0045 National Research Council Canada | 5071 West Saanich Rd, Victoria BC. V9E 2E7 Conseil national de recherches Canada | 5071, ch. West Saanich, Victoria (C.-B) V9E 2E7 Government of Canada | Gouvernement du Canada -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=14056 00 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1523267
RE: Redirector: HTTP request to HTTPS request
Hi Matt,
Were you able to solve this? If not, could you enter a defect report and
attach your test case?
Best regards,
Jerome Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com
-Message d'origine-
De : webp...@tigris.org [mailto:webp...@tigris.org]
Envoyé : mercredi 25 mars 2009 21:23
À : discuss@restlet.tigris.org
Objet : Redirector: HTTP request to HTTPS request
Hello,
I'm using a Redirector in MODE_DISPATCHER. I can easily use it to forward
HTTP requests that come from the client to another URI, e.g.:
http://localhost/forward - http://www.example.com What I'm trying to do
now, is to forward an HTTP request to an HTTPS URI, e.g.:
http://localhost/forward - https://www.example.com In the client (browser)
I get a 200 OK response with the headers:
Content-Length: 0
Date: Wed, 25 Mar 2009 18:01:10 GMT
Accept-Ranges: bytes
Server: Noelios-Restlet-Engine/1.1.3
Connection: close,
which is an empty response with 200 OK.
That much about the problem, here's some code. The TestApp class:
public class TestApp extends Application {
public synchronized Restlet createRoot() {
Router router = new Router(getContext());
Redirector red = new
Redirector(getContext(),https://www.example.com,Redirector.MODE_DISPATCHER
);
router.attach(/redirect,red);
return router;
}
}
and the main method:
public static void main(String[] args) {
try {
Component component = new Component();
component.getClients().add(Protocol.HTTPS);
component.getServers().add(Protocol.HTTP, 8182);
component.getDefaultHost().attachDefault(new TestApp());
component.start();
} catch (Exception e) {
e.printStackTrace();
}
}
Matt
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=14196
12
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1523283
Re: Redirector: HTTP request to HTTPS request
Anecdotally ... I proxy from http to https all the time using Redirector ... the masking to an empty 200 status looks like that perennial Tomcat 5 issue with no-entity responses. On Thu, Apr 2, 2009 at 3:32 PM, Jerome Louvel jerome.lou...@noelios.comwrote: Hi Matt, Were you able to solve this? If not, could you enter a defect report and attach your test case? Best regards, Jerome Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1523369
problem with securityContext.isUserInRole() with new SecurityAPI
hi, I just created new organization, user (login admin, pass admin),
and group using new security API (1.2 M2) . Bind user + group to
organization. Bind group to role ADMIN_ROLE. Set up authorizer
against this role + HTTP_BASIC Guard against appropriate resource (
/admin/*) with this role authorizer.
When point to resource (/admin/subresource), I just pass the admin /
admin credentials (so Guard and authorizer works) and get access to
the page (generated by resource), but the check
securityContext.isUserInRole() in my JAX-RS resource fails against the
ROLE i have just recently been checked. UserPrincipals is still valid
(it shows admin).
Sorry, am i right with the code or just miss something?
public class Application extends org.restlet.Application {
public Application() { this(null); }
public Application(Context context) { super(context);}
public static final String ADMIN_ROLE = ADMIN_ROLE;
@Override
public Restlet createRoot() {
Router router = new Router(getContext());
// create roles
this.getRoles().add(new Role(ADMIN_ROLE, Admin Role));
// create realm (i.e. create users and groups, bind
users to groups, bind groups to roles)
MemoryRealm realm = new MemoryRealm();
Organization org = createOrganization(realm, this); //static
methods
that create org, groups, user + bind to the role group
realm.getOrganizations().add(org);
getContext().setRealm(realm);
// create specific (ADMIN_ONLY) role policy
RoleAuthorizer roleAuthorizer = new RoleAuthorizer();
roleAuthorizer.getAuthorizedRoles().add(this.findRole(ADMIN_ROLE));
// create authentification guard
ChallengeGuard guard = new ChallengeGuard(getContext(),
ChallengeScheme.HTTP_BASIC, Guard);
// create application
JaxRsApplication jaxRsApplication = new
JaxRsApplication(getContext());
jaxRsApplication.add(new JaxRsConfiguration());
//JAXRSConfiguration
extends javax.ws.rs.core.Application+ pick up AdminResource in
getClasses() method.
// set role authorizer to guard
guard.setAuthorizer(roleAuthorizer);
// bind application to guard
guard.setNext(jaxRsApplication);
// attach guard to router
router.attach(/admin, guard);
return router;
}}
-
@Path(/{subresource})
public class AdminResource {
@Context
SecurityContext securityContext;
@GET
public Response station(@PathParam(subresource) String station) {
String role = roleChecker();
return Response.ok(divSubresourse ' + subresource +
', Principal ' +
securityContext.getUserPrincipal().getName() +
, InRole +
securityContext.isUserInRole(Application.ADMIN_ROLE)+ ' /div,
MediaType.TEXT_HTML).build();
}
}
web.xml
?xml version=1.0 encoding=UTF-8?
web-app xmlns:xsi=http://www.w3.org/2001/XMLSchema-instance;
xmlns=http://java.sun.com/xml/ns/javaee;
xmlns:web=http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd;
xsi:schemaLocation=http://java.sun.com/xml/ns/javaee
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd; version=2.5
!-- Restlet adaptor --
servlet
servlet-nameRestletServletAdaptor/servlet-name
servlet-classorg.restlet.ext.servlet.ServerServlet/servlet-class
/servlet
!-- Application class name for adaptor --
context-param
param-nameorg.restlet.application/param-name
param-valuecom.example.services.Application/param-value
/context-param
!-- Catch all requests --
servlet-mapping
servlet-nameRestletServletAdaptor/servlet-name
url-pattern/*/url-pattern
/servlet-mapping
/web-app
--
Best regards,
~ Xasima Xirohata ~
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1523928
ServerResource conditional mode
Hi, Does someone have a grasp on what conditional mode is for and how it used? It's enabled by default, but I had to disable it for one of my resources to work with PUT and POST. The issue is that it always calls doGetInfo first, which for my particular resource will fail, and so calls to PUT and POST also fail. Also, it seems to me that calling doGetInfo for every request, even for methods that are not GET, is wasteful. In short, I simply don't understand why this check happens, and subsequently what exactly conditional mode is doing. :) -Tal
Re: How to authenticate to many websites seamlessly?
Jerome Louvel wrote: Hi Rickard, Now that 1.2 M2 is out, I can get to your email! I would suggest that you try out Restlet 1.2 M2 if you can. The ClientResource class allows you to set the next Restlet. If can be a Filter chain leading to the Context#clientDispatcher of your Application or leading to a Client instance. Then, you should develop a special Filter that would enrich the request with the correct credentials. You could even use a Router to handle this on a target URI basis! Thanks for the reply! Yes, I figured out on my own that that's what I wanted to do. I built a filter for it. However, your idea with Router might be even better way to do it! thanks, Rickard -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1527368
Re: Restlet 1.2 M2 released [throw previous email away]
Stephan Koops wrote:
Stephan Koops schrieb:
Jonathan Hall schrieb:
Shame you can't have @Get(MediaType.TEXT_HTML). I don't know.
Would it work to change MediaType from class to an enum? That could
work, but I'm not sure
While sending the email I remembered: You can't add new MediaTypes this
way, so we could forget my previous idea.
That depends on how you define the annotation. If it is
@interface Get
{
Enum value();
}
it is fine, since then you can use any enum. Which is better than any
string, since then you get the confusion of Should I use 'xml' 'XML'
'text/xml' or what?. With Enum as baseline you at least have to look at
what someone, somewhere, has defined.
/Rickard
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1527503
Re: Restlet 1.2 M2 released [throw previous email away]
But it's not clear to me why this code should use the MetadataService at all. The mapping of file extensions to MediaTypes is one of the web's irritating but hard to avoid dirty shameful secrets. The only time we should stoop so low as to base a MediaType calculation on an extension name is if we have no other choice- in fact, we only have to do this when we DONT have real metadata available! If I am writing a restful web service, and I want to deliver a representation with a mediatype of image/jpeg, then that's what I should have to put in the @Get annotation- not jpg or jpeg or JPG or any other of the random 3 or 4-letter filename extensions that someone, somewhere, sometime happened to associate (in their anemic filesystem) with that mediatype. (If I sound grumpy it might be because I just spent quite a while with a debugger trying to figure out why my new ServerResource subclass wasn't working, and it turns out it's because I was using text/html instead of htm or whatever. :-) ) So, I vote for explicit mediatypes. and maybe we also need to be able to specify charsets too? Hmm, maybe that's not useful for content negotiation, not sure. -Dave Fogel -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1528590
Re: ServerResource conditional mode
Hi Tal-
I've been struggling with that very question, as I, too had trouble
with POSTing to my new ServerResource subclass.
I also noticed that getPreferredVariant(Method.GET) is called during
processing of the POST request, and I couldn't figure out why.
At first I thought that was the cause of my problems, but it turned
out that my problem was in the 2nd time through getPreferredVariant(),
in doNegotiatedHandle(), this time called with (the correct)
Method.POST. This method was always returning a 406 status -
CLIENT_ERROR_NOT_ACCEPTABLE.
my post method looked something like this:
@Post
public void postSomeData(Representation entity) throws ResourceException {
}
the getPreferredVariant code checks the Java return-type of the
annotated method, and in this case having a void return type meant
that getPreferredVariant returns null, which causes the
doNegotiatedHandle to return 406.
This doesn't seem like quite the right thing, since it's not clear to
me exactly what kind of content negotation can really usefully go on
in the (fairly common) case of a POST method which processes Form data
and then returns 204- success-no-content. It's also not clear to me
whether I should have given the @Post a mediatype value- should this
be the incoming representation type of form-url-encoded, or something
else? not sure at all.
I'd love to see some greater amount of docs or general explanation of
what the thinking is here, or else I fear this will cause significant
confusion for people... I found it particularly confusing how
ServerResource combines support for both annotated and non-annotated
subclasses. Maybe support for these two approaches should be broken
out into two classes?
-Dave Fogel
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1528827
Re: Restlet 1.2 M2 released [throw previous email away]
Hi
David,
I
agree that filename extensions are not the best way to go here, but I
see nothing wrong with supporting them in addition to MIME types. As
for supporting MIME types, it seems we already have a facility in
Restlet via MediaType.valueOf():
http://www.restlet.org/documentation/1.2/api/org/restlet/data/MediaType.html#valueOf(java.lang.String)
If this simple support is added to ServerResource,
then it would be possible to annotate as so:
@Get(MediaType.APPLICATION_JSON.toString()
A tad verbose, but precise and efficient.
Also, I've noticed no error if you use an unsupported extension. I
think we should have an exception thrown if we try to write something
like @Get("fishburger")! Unless a valid MediaType is found, I think it
best the ServerResource fail.
-Tal
David Fogel wrote:
But it's not clear to me why this code should use the
"MetadataService" at all. The mapping of file extensions to
MediaTypes is one of the web's irritating but hard to avoid dirty
shameful secrets. The only time we should stoop so low as to base a
MediaType calculation on an extension name is if we have no other
choice- in fact, we only have to do this when we DONT have real
metadata available!
If I am writing a restful web service, and I want to deliver a
representation with a mediatype of "image/jpeg", then that's what I
should have to put in the @Get annotation- not "jpg" or "jpeg" or
"JPG" or any other of the random 3 or 4-letter filename extensions
that someone, somewhere, sometime happened to associate (in their
anemic filesystem) with that mediatype.
(If I sound grumpy it might be because I just spent quite a while with
a debugger trying to figure out why my new ServerResource subclass
wasn't working, and it turns out it's because I was using "text/html"
instead of "htm" or whatever. :-) )
So, I vote for explicit mediatypes. and maybe we also need to be able
to specify charsets too? Hmm, maybe that's not useful for content
negotiation, not sure.
-Dave Fogel
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1528590
