Re: ClientResource leaves inactive thread
I'm not clear from the question if you're asking about the number of task threads as Tim has explained, or the number of http listener threads, for that use: Server httpServer = new Server(Protocol.HTTP, port); serviceComponent.getServers().add(httpServer); httpServer.getContext().getParameters().add(maxThreads, maxThreads); On Jul 27, 2011, at 2:02 PM, Tim Peierls wrote: You can set the pool size of the executor used by the TaskService with org.restlet.service.TaskService.setPoolSize. Or you can provide your own TaskService and override createExecutorService.to return an ExecutorService tuned exactly the way you want. --tim On Wed, Jul 27, 2011 at 8:14 AM, Klemens Muthmann al...@gmx.de wrote: Hi, I read several threads about this problem now (including this one) and still can't figure out how to solve the issues (My Restlet Version is 2.0.8). May someone point me to the relevant tutorial or show some code on how to increase the thread pool size on the RESTlet Server? Thanks and regards -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2804569 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2805287
Re: How-to for setting up Client PKI Cert based authentication?
Have a look at this: http://restlet-discuss.1400322.n2.nabble.com/fine-grained-authorization-based-on-DN-X-509-td6444949.html Let me know if that answers the question for you... On Tue, Jul 12, 2011 at 2:16 PM, Kevin Pauli ke...@thepaulis.com wrote: This page talks about setting up Basic and Digest based authentication... http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/46-restlet/112-restlet.html I am looking for a guide to setting up Client PKI Cert-based authentication in Restlet 2.0 Can anyone point me in the right direction? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2791113 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2791115
Re: how to use conditional get in restlet ?
I'm moving this to the disc...@restlet.itgris.org, the code list is more for the restlet codebase itself. Anyhow, the answer to your question is two-fold: First, Conditional Get means something very specific in HTTP parlance and it isn't what you describe. A conditional get is a GET request that sends a special header that tells the server to not bother to send a response if the resource that is being requested hasn't been modified since the last time the client made the request. So it isn't really for what you're talking about. So, to do what you'd like to do, just use a query parameter. For example: http://www.example.com/people?age=over20 -Matt On Jun 15, 2011, at 4:08 PM, infoSyS wrote: I am currently designing an API using the restlet framework; Can anyone please give me a clue on how to use conditional GET requests in RESTlet ? what I mean is : lets say I have the name and date of birth of many persons and I want to GET the name of persons that are older than 20 years, how could this be done ? Thanks in advance. -- View this message in context: http://restlet-code.1609877.n2.nabble.com/how-to-use-conditional-get-in-restlet-tp6480367p6480367.html Sent from the Restlet Code mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458dsMessageId=2766359 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2766749
Re: fine grained authorization based on DN/X.509
That's one way to do it, but it isn't the way I usually design my restlet
applications.
I do all of my authentication and authorization in subclasses of the restlet
API classes, which are subclasses of filter. These typically sit in front
of your resources in a filter chain, which you configure in your router set
up in createInboundRoute in your subclass of Application.
Steps 9-12 of http://www.restlet.org/documentation/2.0/tutorial have an
example that may be useful to you. But if what you have works for your
situation, then it looks like you're on the right track. It just may be
harder to re-use your code in other restlet applications later on.
-Matt
On Tue, Jun 7, 2011 at 6:31 AM, lambda daku lambdad...@gmail.com wrote:
Thanks for the reply.
I have few comments on your reply.
Usually the certificate received at the server side has atleast 2
certificates - one is a public key of the client and the rest are n
trusted entries (in my case it is 1).
As you have mentioned about the getRequest() method, where do you access it
in a resource or in a application class? I am intercepting the requests in
an application class (which extends from JaxRsApplication), whereby I am
overriding the handle(req,res) method and and getting the desired
attributes, is the following were you referring to?:
public class MyJaxRsApplication extends JaxRsApplication{
@Override
public void handle(Request request, Response response) {
Maplt;String, Objectgt; map = request.getAttributes();
@SuppressWarnings(unchecked)
ListX509Certificate lst = (ListX509Certificate)
map.get(org.restlet.https.clientCertificates);
//however the first item in the above list is the user's public key
//here, delegation to the authorization PEP, PAP and PIP will be made
}
..
}
Many thanks
Daku
--
View this message in context:
http://restlet-discuss.1400322.n2.nabble.com/fine-grained-authorization-based-on-DN-X-509-tp6444949p6448938.html
Sent from the Restlet Discuss mailing list archive at Nabble.com.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2759531
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2759653
Re: fine grained authorization based on DN/X.509
There are two steps here, authenticating the client cert, and authorizing the user, which correspond to the org.restlet.routing.filter.Authenticator and org.restlet.routing.filter.Authorizer classes. These sit in front of the resource you are controlling access to. In the cases of client certificates, the authenticator is really merely checking for the existence of client certs available on the connection, the SSL layer has already verified them and stashed them where restlet can access them, which is: getRequest().getAttributes().get(org.restlet.https.clientCertificates), which gives you a list (usually of length 1) of java.security.cert.X509Certificate objects I think. You can use that to get the DN, and then I would put that in a field of the restlet User object or a custom subclass thereof. Then when it gets to your authorizer, you use the DN you pulled off the cert to query an LDAP to determine if the user can do what they are attempting or not. This is a good place to start research. I could have sworn that at one point Bruno Harbulot had posted a patch for a ClientCertAuthenticator.java to the issue tracker, but I have no clue what happened to it. -Matt On Mon, Jun 6, 2011 at 8:44 AM, lambda daku lambdad...@gmail.com wrote: Hi, I have a Restlet application running on jetty usiing https (with client side authn). The required behavior is to intercept the client request and extract the DN on the server side (in-bound), on which the authorization will take place. Whereby the DN/x.509 would be matched against some external entity (ldap) where the DN/x.509 certs are stored. Is there any standard way to add interceptors on the client as well as on the server side to authorize the user based on a particular DN/x.509 or any other credential? Thanks Daku -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/fine-grained-authorization-based-on-DN-X-509-tp6444949p6444949.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2759025 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2759110
Re: fine grained authorization based on DN/X.509
Sorry, forgot to include the link: http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet.html On Mon, Jun 6, 2011 at 2:20 PM, Matt Kennedy stinkym...@gmail.com wrote: There are two steps here, authenticating the client cert, and authorizing the user, which correspond to the org.restlet.routing.filter.Authenticator and org.restlet.routing.filter.Authorizer classes. These sit in front of the resource you are controlling access to. In the cases of client certificates, the authenticator is really merely checking for the existence of client certs available on the connection, the SSL layer has already verified them and stashed them where restlet can access them, which is: getRequest().getAttributes().get(org.restlet.https.clientCertificates), which gives you a list (usually of length 1) of java.security.cert.X509Certificate objects I think. You can use that to get the DN, and then I would put that in a field of the restlet User object or a custom subclass thereof. Then when it gets to your authorizer, you use the DN you pulled off the cert to query an LDAP to determine if the user can do what they are attempting or not. This is a good place to start research. I could have sworn that at one point Bruno Harbulot had posted a patch for a ClientCertAuthenticator.java to the issue tracker, but I have no clue what happened to it. -Matt On Mon, Jun 6, 2011 at 8:44 AM, lambda daku lambdad...@gmail.com wrote: Hi, I have a Restlet application running on jetty usiing https (with client side authn). The required behavior is to intercept the client request and extract the DN on the server side (in-bound), on which the authorization will take place. Whereby the DN/x.509 would be matched against some external entity (ldap) where the DN/x.509 certs are stored. Is there any standard way to add interceptors on the client as well as on the server side to authorize the user based on a particular DN/x.509 or any other credential? Thanks Daku -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/fine-grained-authorization-based-on-DN-X-509-tp6444949p6444949.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2759025 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2759111
Re: fine grained authorization based on DN/X.509
And that was the wrong link, sorry: http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/46-restlet.html On Mon, Jun 6, 2011 at 2:21 PM, Matt Kennedy stinkym...@gmail.com wrote: Sorry, forgot to include the link: http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet.html On Mon, Jun 6, 2011 at 2:20 PM, Matt Kennedy stinkym...@gmail.com wrote: There are two steps here, authenticating the client cert, and authorizing the user, which correspond to the org.restlet.routing.filter.Authenticator and org.restlet.routing.filter.Authorizer classes. These sit in front of the resource you are controlling access to. In the cases of client certificates, the authenticator is really merely checking for the existence of client certs available on the connection, the SSL layer has already verified them and stashed them where restlet can access them, which is: getRequest().getAttributes().get(org.restlet.https.clientCertificates), which gives you a list (usually of length 1) of java.security.cert.X509Certificate objects I think. You can use that to get the DN, and then I would put that in a field of the restlet User object or a custom subclass thereof. Then when it gets to your authorizer, you use the DN you pulled off the cert to query an LDAP to determine if the user can do what they are attempting or not. This is a good place to start research. I could have sworn that at one point Bruno Harbulot had posted a patch for a ClientCertAuthenticator.java to the issue tracker, but I have no clue what happened to it. -Matt On Mon, Jun 6, 2011 at 8:44 AM, lambda daku lambdad...@gmail.com wrote: Hi, I have a Restlet application running on jetty usiing https (with client side authn). The required behavior is to intercept the client request and extract the DN on the server side (in-bound), on which the authorization will take place. Whereby the DN/x.509 would be matched against some external entity (ldap) where the DN/x.509 certs are stored. Is there any standard way to add interceptors on the client as well as on the server side to authorize the user based on a particular DN/x.509 or any other credential? Thanks Daku -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/fine-grained-authorization-based-on-DN-X-509-tp6444949p6444949.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2759025 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2759112
Re: Using the simple framework in Restlet
It should be as simple as having $RESTLET_HOME/lib/org.restlet.ext.simple.jar and $RESTLET_HOME/lib/org.simpleframework_N.N/org.simpleframework.jar on your classpath. On Thu, May 5, 2011 at 7:20 AM, Steve Ferris steve.fer...@forgerock.comwrote: Hi, I cannot work out how to tell my standalone Restlet application to the use the Simple framework as it's chosen server connector. Is this some method I have to call or property to set? I am using maven and have included the correct dependency. thanks Steve -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2730537 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2731085
Re: Fine grained authorization
You would typically call isInRole() in the ServerResource methods that you override to determine if a particular user can perform some action. You may also want to look at the MethodAuthorizer if you want to allow some users access to all the HTTP methods, but restrict others to GET POST for example. That way your annotated methods don't have to have authorization code in them, they simply won't be called if the user isn't allowed to call them by the MethodAuthorizer -Matt On Fri, Apr 15, 2011 at 1:57 AM, Ishaaq Chandy ish...@gmail.com wrote: Hi all, Am using Restlet 2.0.6. Trying to figure out how to implement fine grained authorization on my Resources. The authorization checks need to be instance-specific. According to http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/46-restlet/113-restlet.html, I should be able to leverage ServerResource.isInRole() for this. However, I can't see how this works even if I implement that method as I see nothing in the Restlet source code that actually calls it other that some old deprecated jaxrs code. Suggestions? Ishaaq -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2721415
Re: Auditing function
I've done something similar in the past. Rather than rely on the restlet access logging service, I collected all the data I needed in an object as the request was processed. After the request completed, I spun off another thread to write to the log object to the database. If the database wasn't available, I did backup logging to a file. I _think_ I did this in the confines of wither log4j or slf4j, but I can't remember. On Sun, Apr 3, 2011 at 8:31 PM, Paul Morris pmor...@nmh.org wrote: I've been looking into this since my initial post and want to add a couple of thoughts to clarify my intention here. I found the LogService Restlet class which looks very robust but I need to customize some of the logging here for auditing and compliance purposes (i.e. identify the user based on querying a session server using a token) so I think I'm looking at something homegrown. But again, I'd like to implement some way to sort of copy the request on the way in and copy the response on the way out, parse through those copies (perhaps in another thread) to break them out cleanly into a database. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2716636 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2719277
Re: Retrying requests
I usually do this sort of thing in the ServerResource itself. Just wrap the
problematic lines in the code you just provided only replace the call to
super.handle with whatever calls throw the exception. Are you doing something
in particular that makes this a bad strategy?
-Matt
On May 5, 2010, at 8:45 PM, Jean-Philippe Steinmetz wrote:
Hello everyone,
I have a restlet resource that sometimes produces an exception during
processing. Since the exception is the fault of the server and not the fault
of the client I would like to retry the request. When an exception occurs I
get rolled back all the way to the Finder. In the Finder's handle function
i'd like to attempt to retry processing of the request when I see these
exceptions. Here's an example of the Finder I would like to implement.
@Override
public void handle(Request request, Response response)
{
int count = 0;
while (count MAX_RETRIES)
{
try
{
super.handle(request, response);
break;
} catch (MyException e) {
count++;
}
}
}
The behavior i'm seeing, however, is that once the exception is caught the
response is immediately sent back to the client and retry processing ceases.
If this is expected behavior how would I go about making this happen?
Jean-Philippe
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2603796
Re: Retrying requests
You can probably save yourself a lot of work by inserting an extra level of
inheritance. It is a pain to throw in try-catch blocks all over the place, but
if you think about it you might be able to put your try loop in a new
superclass to your resources and get the same functionality. It is usually
fairly easy to change around your inheritance hierarchy and change some method
names, especially if you have a nice refactoring helper like Eclipse.
-Matt
On May 5, 2010, at 9:06 PM, Jean-Philippe Steinmetz wrote:
I just tested that scenario out and it works. Unfortunately though the way
it's all coded up so far requires a lot more code refactoring to edit each
resource than it would be to handle it in the Finder itself. Albeit it would
probably be more correct. Just trying to save myself some time =)
On Wed, May 5, 2010 at 5:56 PM, Matt Kennedy stinkym...@gmail.com wrote:
I usually do this sort of thing in the ServerResource itself. Just wrap the
problematic lines in the code you just provided only replace the call to
super.handle with whatever calls throw the exception. Are you doing
something in particular that makes this a bad strategy?
-Matt
On May 5, 2010, at 8:45 PM, Jean-Philippe Steinmetz wrote:
Hello everyone,
I have a restlet resource that sometimes produces an exception during
processing. Since the exception is the fault of the server and not the fault
of the client I would like to retry the request. When an exception occurs I
get rolled back all the way to the Finder. In the Finder's handle function
i'd like to attempt to retry processing of the request when I see these
exceptions. Here's an example of the Finder I would like to implement.
@Override
public void handle(Request request, Response response)
{
int count = 0;
while (count MAX_RETRIES)
{
try
{
super.handle(request, response);
break;
} catch (MyException e) {
count++;
}
}
}
The behavior i'm seeing, however, is that once the exception is caught the
response is immediately sent back to the client and retry processing ceases.
If this is expected behavior how would I go about making this happen?
Jean-Philippe
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2603822
Re: What to do about sessions?
Dj, I'm glad you asked this. I've really lucked out so far and have always worked in an environment that uses client certificates for authentication. The identity of the user is established on every single connection, and I never have to worry about it. But in the near future, I'm going to have to solve the same problem that you're looking at now. You make some astute observations, HTTP_BASIC is only safe over HTTPS, which is very limiting, especially when deploying to GAE. HTTP_DIGEST has some poorly understood compatibility problems with different HTTP clients, furthermore, it isn't what GAE uses natively. It seems that for the GAE edition in particular it would be nice to have an Authenticator that could integrate with the GAE APIs. I'm sure if it isn't done by the time I have to tackle that project that I'll wind up writing one. Does the restlet team have any specific advice for creating a subclass of Authenticator that can get the Google account identity? Specifically a way to use a restlet to write the login example given on this link: http://code.google.com/appengine/docs/java/users/overview.html -Matt On Apr 20, 2010, at 11:37 AM, dj wrote: Hey Stephen, Ok so I get that sessions shouldn't be supported by rest, totally fine with that. I'm confused about how to use basic auth then instead, if that's the preferred method. If we use basic auth, then we need to send the username and password as plain text, right? This could be fixed by using https. But this also implies that every rest call made must supply username:password in the request, right? In that case, then in order to protect the user, every rest call should be done using https. Is that correct? Thanks -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590591 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2590628
Re: Representation for multiple types?
Can you just use the sample code you provide below, only create a subclass of
Representation that takes your serializer as the argument, maybe along with the
mime type? Something like:
public class MyVariableRepresentation extends Representation
{
Serializer serializer;
public MyVariableRepresentation(MediaType type, Serializer variantSerializer)
{
super(type);
this.serializer = variantSerializer;
}
//Then override write method or something to call your serializer to do the
serializing.
}
So your sample code becomes:
public class MyResource extends Resource
{
public MapMediaType,Serializer map;
public Representation represent(Variant variant) throws ResourceException
{
Serializer serializer = map.get(variant.getMediaType());
if (serializer == null)
throw new
ResourceException(Status.CLIENT_ERROR_UNSUPPORTED_MEDIA_TYPE);
return new MyVariableRepresentation(variant.getMediaType(),
serializer.encode(data)); // ??
}
}
Does this work?
On Jan 22, 2010, at 6:27 PM, Jean-Philippe Steinmetz wrote:
Sure. With our particular use case we specify a map of media types to data
serializers in spring as a hash map. We then inject this map into each
resource. When the map is set in the class we then add all the media types
specified as map keys as acceptable variants. When the represent() function
is called we use the provided media type to retrieve the associated
serializer, throwing an unsupported media type error if the variant has no
corresponding serializer. We then serialize our data and send it back to the
client. It's the sending it back to the client part is where I am stuck. As
there is no default Representation class that I can merely pass in any object
type to whether it be string, bye array, etc.
Here is an example of the Resource class.
public class MyResource extends Resource
{
public MapMediaType,Serializer map;
public Representation represent(Variant variant) throws ResourceException
{
Serializer serializer = map.get(variant.getMediaType());
if (serializer == null)
throw new
ResourceException(Status.CLIENT_ERROR_UNSUPPORTED_MEDIA_TYPE);
return new Representation(serializer.encode(data)); // ??
}
}
Here is an example of our spring applicationContext.xml.
beans
...
util:map id=map map-class=java.util.HashMap
entry
keyutil:constant
static-field=org.restlet.data.MediaType.APPLICATION_FLASH//key
ref local=amfSerializer/
/entry
entry
keyutil:constant
static-field=org.restlet.data.MediaType.APPLICATION_JSON//key
ref local=jsonSerializer/
/entry
entry
keyutil:constant
static-field=org.restlet.data.MediaType.APPLICATION_XML//key
ref local=xmlSerializer/
/entry
/util:map
bean name=/my/resource id=myResource autowire=byName
scope=prototype
class=com.restlets.MyResource
property name=map ref=map/
/bean
...
/beans
On Fri, Jan 22, 2010 at 3:07 PM, Matt Kennedy stinkym...@gmail.com wrote:
I'm not a Spring user, so maybe that's why it isn't clear to me what you're
asking. Can you try phrasing this question a different way? I think I know
the answer to your problem because I've always had to deal with multiple
media types for the same resource, but I'm not sure I understand the problem.
Can you walk through a use-case?
On Jan 22, 2010, at 6:00 PM, Jean-Philippe Steinmetz wrote:
Thank you for the quick reply. This certainly would resolve the issue but it
doesn't really offer the kind of solution I was hoping for. With this
solution i'd still have to do a mapping of media type to some representation
which is what I am trying to avoid. The thought was that there is a
Representation that just outputs the message body regardless of whatever
media type variant is set for it. That way I don't have to make a mapping of
media type to anything.
On Fri, Jan 22, 2010 at 1:27 PM, Matt Kennedy stinkym...@gmail.com wrote:
I can't remember what 1.1.6's API looks like, but I do something like this
with the 2.0 API. Basically, in the Resource's constructor, I use someting
like:
getVariants().add(new MyXMLRepresentation(this))
getVariants().add(new MyJSONRepresentation(this))
Each of those My* classes are a subclass of Representation, and the write()
method is overridden to produce the custom media type. I pass the Resource
object to the custom representation so that I have access to the resource
during the write method. Also important is that in the constructor, you
call the super constructor with the MediaType and resource as arguments, ex:
//Constructor
public MyJSONRepresentation(Resource res)
{
super(MediaType.APPLICATION_JSON, res);
}
I know something like this can be done with the 1.1.6 API
Re: Representation for multiple types?
I can't remember what 1.1.6's API looks like, but I do something like this with
the 2.0 API. Basically, in the Resource's constructor, I use someting like:
getVariants().add(new MyXMLRepresentation(this))
getVariants().add(new MyJSONRepresentation(this))
Each of those My* classes are a subclass of Representation, and the write()
method is overridden to produce the custom media type. I pass the Resource
object to the custom representation so that I have access to the resource
during the write method. Also important is that in the constructor, you call
the super constructor with the MediaType and resource as arguments, ex:
//Constructor
public MyJSONRepresentation(Resource res)
{
super(MediaType.APPLICATION_JSON, res);
}
I know something like this can be done with the 1.1.6 API because I was using
it before I ported to 2.0, but now I can't find the 1.1.6 code. It probably
isn't too different.
On Jan 22, 2010, at 3:50 PM, Jean-Philippe Steinmetz wrote:
Hello all,
We're using restlet 1.1.6 and for all our resources we want to support a
dynamic set of media types. We do this in our Spring configuration by setting
up a list of acceptable media types. My question is if there is a
Representation class I can use that will essentially accept any type of data
I push into it? For instance we support HTML, XML, JSON and AMF3 therefore
most of the time it's a string based representation but in the case of AMF3
it is binary (byte array). So far the only way I see it is to make a switch
statement in our resource class for each media type but this pretty much
defeats the purpose of specifying supported media types in the application
configuration.
Jean-Philippe
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2441312
Re: Representation for multiple types?
I'm not a Spring user, so maybe that's why it isn't clear to me what you're
asking. Can you try phrasing this question a different way? I think I know
the answer to your problem because I've always had to deal with multiple media
types for the same resource, but I'm not sure I understand the problem. Can
you walk through a use-case?
On Jan 22, 2010, at 6:00 PM, Jean-Philippe Steinmetz wrote:
Thank you for the quick reply. This certainly would resolve the issue but it
doesn't really offer the kind of solution I was hoping for. With this
solution i'd still have to do a mapping of media type to some representation
which is what I am trying to avoid. The thought was that there is a
Representation that just outputs the message body regardless of whatever
media type variant is set for it. That way I don't have to make a mapping of
media type to anything.
On Fri, Jan 22, 2010 at 1:27 PM, Matt Kennedy stinkym...@gmail.com wrote:
I can't remember what 1.1.6's API looks like, but I do something like this
with the 2.0 API. Basically, in the Resource's constructor, I use someting
like:
getVariants().add(new MyXMLRepresentation(this))
getVariants().add(new MyJSONRepresentation(this))
Each of those My* classes are a subclass of Representation, and the write()
method is overridden to produce the custom media type. I pass the Resource
object to the custom representation so that I have access to the resource
during the write method. Also important is that in the constructor, you call
the super constructor with the MediaType and resource as arguments, ex:
//Constructor
public MyJSONRepresentation(Resource res)
{
super(MediaType.APPLICATION_JSON, res);
}
I know something like this can be done with the 1.1.6 API because I was using
it before I ported to 2.0, but now I can't find the 1.1.6 code. It probably
isn't too different.
On Jan 22, 2010, at 3:50 PM, Jean-Philippe Steinmetz wrote:
Hello all,
We're using restlet 1.1.6 and for all our resources we want to support a
dynamic set of media types. We do this in our Spring configuration by
setting up a list of acceptable media types. My question is if there is a
Representation class I can use that will essentially accept any type of
data I push into it? For instance we support HTML, XML, JSON and AMF3
therefore most of the time it's a string based representation but in the
case of AMF3 it is binary (byte array). So far the only way I see it is to
make a switch statement in our resource class for each media type but this
pretty much defeats the purpose of specifying supported media types in the
application configuration.
Jean-Philippe
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2441312
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2441343
Re: Applying multiple security scheme's to a uri
Are you using the 2.0 API? You can subclass the Authenticator and override the authenticate() method. That gives you access to the Request object, you should then be able to check the user-agent and do custom authentication. Authenticator is a filter, so you will have to call setNext() to specify the next resource in the chain, either an instance of an Authorizer, or your restlet usually. -Matt On Jan 11, 2010, at 9:44 AM, webp...@tigris.org wrote: Hello, Given the user-agent property, is it possible to apply different security scheme's to a given uri? i.e. when using a browser apply basic or digest security, but when using any other 'client', use a custom security scheme. Right now, my authentication is setup once-off in the 'createInboundRoot' method. But this method is never invoked again after that. Is there a hook/method i can use to specify which scheme to use based on the user agent? Regards, --KD -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2436294 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2436312
Re: Redirection?
I guess I'm not clear on your motivation for trying to accomplish this on the server. The easy way to do a redirect to another page if you want the original page to be displayed for a set period of time is to return html that has a special meta tag in the head section. See http://en.wikipedia.org/wiki/Meta_refresh for examples. You can put an animated gif in for the countdown, or write some javascript to do the countdown. If you want this to be an official HTTP redirect, for example a 301, 302, 303, 307 status code, then you can set that status code in the response object and set the entity to be some html that will do your refresh to the new URL, plus the countdown. Be careful if you choose to go with 301 or 302 as the response code, read IETF RFC 2626 for details. -Matt -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2433460
Re: Redirection?
RFC 2616 :-) http://www.ietf.org/rfc/rfc2616.txt (2626 is the Y2K RFC)
Woops. Hm, next time I should probably copy/paste the link instead of
fat-fingering the name huh?
Rob is right about everything else here too, I should have made it more clear
that the meta-refresh trick is hardly optimal as the wikipedia entry nicely
states. It sounded like the countdown part was really important to you though,
but the combination of a redirect status code and the meta-refresh header may
give you really inconsistent results. Do you know if you have the luxury of
your client base only using a particular user agent?
If you decide the countdown is that important, you may have to forgo HTTP
correctness and leave the status at 200. Despite it's deprecated status, the
meta-refresh at this moment still works in all the browsers I have experience
with if it isn't also contending with a refresh directive. You can definitely
use it to get your delayed redirect effect.
-Matt
On Dec 28, 2009, at 2:18 PM, Rob Heittman wrote:
RFC 2616 :-) http://www.ietf.org/rfc/rfc2616.txt (2626 is the Y2K RFC)
Sopasakis -- as HTTP itself doesn't have a means of specifying a delay before
a redirect, you won't get consistent behavior across every HTTP compliant
client or library. Most user-agents will act immediately on an HTTP redirect
status code (3xx) and ignore the entity, but supplying an HTML entity with
the meta refresh tag may have the desired effect for some user-agents.
The usual convention is to enclose a short HTML entity with a 3xx redirect,
something like this:
htmlheadtitleMoved/title/headbody
Please click this link if you are not automatically redirected to: a
href=${new-location}${new-location}/a
scriptwindow.location.href=$[new-location};/script
/body
You can doctor up some variants of this using the meta refresh or Javascript
timeouts, but I suspect getting consistent behavior across basic HTTP clients
like curl and regular browsers like Firefox will be a challenge, since you're
operating at the HTML/JS level and not really the HTTP level. If you find a
great solution, please post it back!
- Rob
On Mon, Dec 28, 2009 at 1:42 PM, Matt Kennedy stinkym...@gmail.com wrote:
If you want this to be an official HTTP redirect, for example a 301, 302,
303, 307 status code, then you can set that status code in the response
object and set the entity to be some html that will do your refresh to the
new URL, plus the countdown. Be careful if you choose to go with 301 or 302
as the response code, read IETF RFC 2626 for details.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2433470
Re: how to set up client certificate in restlet 1.1.4 for HTTPS?
Here's the server code I use, my keys/certs may be set up a little
differently from yours though, but this code supports client cert handshakes
using browser clients and curl clients. In this case, the CAs that sign the
client certs are stored in /etc/pki/ca.jks along with the CA that signed
that ewallet.p12 file. Unfortunately, I don't have any restlet client code
to send you, but you can try testing by setting up a client cert in Firefox.
static void setUpSSL(Context workingCtx)
{
System.setProperty('javax.net.ssl.trustStore','/etc/pki/ca.jks');
System.setProperty('javax.net.ssl.trustStorePassword',
System.getenv('TRUSTSTORE_PASS'));
workingCtx.getParameters().add(sslContextFactory,
org.restlet.ext.ssl.PkixSslContextFactory);
workingCtx.getParameters().add(keystorePath,
/etc/pki/wallets/${System.getenv('VIRTUAL_HOST')}/ewallet.p12);
workingCtx.getParameters().add(keystorePassword,
System.getenv('KEYSTORE_PASS'));
workingCtx.getParameters().add(keystoreType, PKCS12);
workingCtx.getParameters().add(keyPassword,
System.getenv('KEY_PASS'));
workingCtx.getParameters().add(certAlgorithm, SunX509);
}
On Wed, Dec 16, 2009 at 11:06 AM, webp...@tigris.org wrote:
Hi,
I'm trying to use the Simple HTTPS library to set up a HTTPS connection
with mutual PKI authentication, after successful server-only authentication.
For the server-only authentication, I created a JKS keystore and modified
the client/server samples in
src\org.restlet.example\org\restlet\example\book\restlet\ch11\{BasicHttpsServer.java,BasicHttpsClient.java}
to load that store.
The client GET request returned the 200 OK.
For the mutual authentication, the BasicHttpsServer.java becomes:
System.setProperty(javax.net.ssl.trustStore,
keystoreFile.getAbsolutePath());
System.setProperty(javax.net.ssl.trustStorePassword, changeit);
// Component declaring only one HTTPS server connector.
Component component = new Component();
Server server = component.getServers().add(Protocol.HTTPS, 8182);
component.getDefaultHost().attach(/helloWorld, restlet);
// Update server's context with keystore parameters.
server.getContext().getParameters().add(keystorePath,
keystoreFile.getAbsolutePath());
server.getContext().getParameters().add(keystorePassword,
changeit);
server.getContext().getParameters().add(keyPassword, server);
server.getContext().getParameters().add(needClientAuthentication,
true);
and the BasicHttpsClient.java becomes:
System.setProperty(javax.net.ssl.trustStore,
keystoreFile.getAbsolutePath());
System.setProperty(javax.net.ssl.trustStorePassword, changeit);
Component component = new Component();
Client client = component.getClients().add(Protocol.HTTPS);
client.getContext().getParameters().add(keystorePath,
keystoreFile.getAbsolutePath());
client.getContext().getParameters().add(keystorePassword,
changeit);
client.getContext().getParameters().add(keyPassword, server);
which is very similar to the server. I used the same jks keystore file for
both client and server to make sure they have the same CA. However, the
client GET request returns this error status:
Communication Error (1001) - Software caused connection abort: recv failed
I also tried to load client side keystore with these:
System.setProperty(javax.net.ssl.keyStore,
keystoreFile.getAbsolutePath());
System.setProperty(javax.net.ssl.keyStorePassword, changeit);
But I got an error status:
Communication Error (1001) - Default SSL context init failed: Cannot
recover key
I suspect the client would not find the key from the keystore because Java
does not provide such property javax.net.ssl.keyPassword.
Does anyone know what is wrong?
For mutual authentication, how do I set up the trustStore on the server
side, and how do I set up the keystore on the client side?
Thanks a lot.
Li
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2430830
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2430838
Re: Unauthenticated access returns 204.
I've always thought that 401 Not Authorized was poorly chosen wording, because it really says the same thing as 403 Forbidden. However, the requirement that a 401 status also MUST send a WWW-Authenticate header I think in practice has led 401 to really mean Not Authenticated and 403 to really mean Not Authorized. Whereas in the description of 403 in rfc2616 section 10 explicitly states that Authentication will not help, which implies that either no authentication is possible, the user is simply trying to do something the server doesn't want done, or it implies that the user is in fact authenticated, and the server is saying the authenticated user isn't authorized to do that. So where does that leave us? I guess I think that the abstract implementation of Authenticator should not simply return 204 to the client if Authentication has been set to be required, and a concrete subclass has returned false in the authenticate() method. It is OK, because it does in fact stop the filter, but I think it could be a little bit easier on the programmer implementing the concrete subclass. Perhaps setting the status to 403 is more appropriate in this case. Anyway, I trust the restlet team's judgement here, but if you decide to keep the behavior as it is, then I encourage you to document clearly that the unauthenticated() method will also need to be overridden in subclasses in order to produce behavior that results in a 401 or 403 upon returning false from the authenticate() method. I would be happy to look at possible implementations of changing the default behavior if it is something the restlet team thinks would be worthwhile. The good news is that as far as my current project goes, I have custom subclasses of Authenticators and Authorizers working very well and I really like the new security architecture, I'm just trying to figure out if this particular aspect of the behavior is as simple as it could be. Thanks for your time, Matt -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2429029
Re: Unauthenticated access returns 204.
Stephan, I did call a 204 an error, didn't I? I should know better.
I have done some digging and I think I see what's going on. The
unauthenticated() method in the abstract Authenticator class never sets
CLIENT_ERROR_UNAUTHORIZED in the response object. I don't know whether it
should or not. It makes subclassing Authenticator slightly easier if it does
set that status. It seems to me that if authentication is not optional, and it
gets as far as the unauthenticated() method, then in addition to setting any
challengeResponse.authenticated property to false and the
clientInfo.authenticated property to false, the method can go ahead and set the
status in the response object as well. Otherwise, anybody writing a subclass of
Authenticator will have to subclass the unauthenticated() method as well in
order to return a 401. Which is completely fine, it just isn't as simple. I'm
going to get a checkout of svn tomorrow and I'll see if I can make this change
without breaking anything and submit the code if everything works OK.
-Matt
On Dec 5, 2009, at 8:16 AM, Stephan Koops wrote:
Hi Matt,
maybe the reason is, that the status is set to 204, if there is no
entity (by Restlet). This must onky be done, if status is 200. Maybe
this check is missing. Try to check it with the debugger.
BTW: 204 is not an error, it means ok, but no entity available.
best regards
Stephan
Matt Kennedy schrieb:
I'm trying to implement a custom authenticator class and I'm a little
stumped by the behavior so far. When I override the authenticate() method
to always return false, I get back an HTTP 204 error. However, if I have it
always return true, then the request goes through correctly, so I think I
have everything wired up the right way. Based on my reading of the
available documentation, if authentication is set as required in the
Authenticator subclass (which is the default setting), then a 401 response
should be sent. Is this a bug? Or am I missing a required step in my
subclass implementation?
Thanks,
Matt
The following illustrates the problem (in Groovy):
import org.restlet.*;
import org.restlet.data.*;
import org.restlet.security.Authenticator;
import org.restlet.representation.*;
class TestAuthenticator extends Authenticator
{
@Override
public TestAuthenticator(Context ctx){ super(ctx); }
@Override
protected boolean authenticate(Request request, Response response)
{
return false;
//return true;
}
}
class TestRestlet extends Restlet
{
@Override
public void handle(Request request, Response response)
{
response.setEntity(new StringRepresentation(hello, world\n,
MediaType.TEXT_PLAIN));
}
}
def component = new Component();
Server http = component.servers.add(Protocol.HTTP, 8181);
component.clients.add(Protocol.FILE);
Context workingCtx = http.context;
def guard = new TestAuthenticator(workingCtx);
def restlet = new TestRestlet();
guard.setNext(restlet);
component.defaultHost.attach(guard);
component.start();
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426801
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2427447
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2428725
Unauthenticated access returns 204.
I'm trying to implement a custom authenticator class and I'm a little stumped
by the behavior so far. When I override the authenticate() method to always
return false, I get back an HTTP 204 error. However, if I have it always
return true, then the request goes through correctly, so I think I have
everything wired up the right way. Based on my reading of the available
documentation, if authentication is set as required in the Authenticator
subclass (which is the default setting), then a 401 response should be sent.
Is this a bug? Or am I missing a required step in my subclass implementation?
Thanks,
Matt
The following illustrates the problem (in Groovy):
import org.restlet.*;
import org.restlet.data.*;
import org.restlet.security.Authenticator;
import org.restlet.representation.*;
class TestAuthenticator extends Authenticator
{
@Override
public TestAuthenticator(Context ctx){ super(ctx); }
@Override
protected boolean authenticate(Request request, Response response)
{
return false;
//return true;
}
}
class TestRestlet extends Restlet
{
@Override
public void handle(Request request, Response response)
{
response.setEntity(new StringRepresentation(hello, world\n,
MediaType.TEXT_PLAIN));
}
}
def component = new Component();
Server http = component.servers.add(Protocol.HTTP, 8181);
component.clients.add(Protocol.FILE);
Context workingCtx = http.context;
def guard = new TestAuthenticator(workingCtx);
def restlet = new TestRestlet();
guard.setNext(restlet);
component.defaultHost.attach(guard);
component.start();
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426801
Re: file extension changes on PUT
Thierry,
This work-around is perfect for my current needs, thanks.
-Matt
On Nov 19, 2009, at 4:29 AM, Thierry Boileau wrote:
Hello Matt,
the current directory is based on a mapping between extensions and media
types (see the javadoc of the method MetadataService#addCommonExtensions).
At this time, the extensions jpe, jpg, jpeg are all mapped with
the media type MediaType.IMAGE_JPEG, with a preference for the first
one. This can be updated by calling the #addExtension(String, Metadata,
boolean) method.
This mapping does clearly not define a bijection, which leads to your
reported errors, in case the served directory contains already files
with unpreferred extensions such as jpg and jpeg.
I've entered an issue for this:
http://restlet.tigris.org/issues/show_bug.cgi?id=953.
Best regards,
Thierry Boileau
I have found some behavior that I think is incorrect when a jpeg is
PUT to a Directory. I wrote a test server in groovy and a client in
curl to illustrate the problem, see below. In summary, when a jpeg
image is PUT into a Directory resource with a URL like
http://host:port/tmp.jpg, the file extension gets changed to .jpe. A
subsequent retrieval of the same URL does work, but directory listings
show the wrong file name. Similarly, and the reason this is a
problem for me, other programs that run on the server need to deal
with the files with the same name that users PUT as the resource
name. In this case, I need users to be able to overwrite a file
called tmp.jpg that already exists in the directory. Instead, I wind
up with two files, tmp.jpg and tmp.jpe. When the user subsequently
request http://host:port/tmp.jpg immediately after they perform a PUT,
they get the original image back, not the one that they just PUT to
the system to replace the original.
I suspect this might happen with other media types that have multiple
valid extensions.
I am testing against 2.0m5 for jse. I tried to test this with a
recent checkout from svn, but building yielded some gwt errors I don't
know how to work around.
Is this a configuration problem on my end? Or could this be a bug?
Thanks for your time,
Matt
//Groovy test server, I can rewrite this is java if necessary.
import org.restlet.*;
import org.restlet.resource.Directory;
import org.restlet.data.Protocol;
class TestDirApp extends Application
{
@Override
public Restlet createInboundRoot()
{
def dir = new Directory(getContext(), 'file:///tmp')
dir.modifiable = true;
//dir.negotiateContent = false; //NB have tried this both ways
println(Negotiating: ${dir.isNegotiateContent()});
dir.listingAllowed = true;
return dir;
}
}
def component = new Component();
Server http = component.servers.add(Protocol.HTTP, 8181);
component.clients.add(Protocol.FILE);
Context workingCtx = http.context;
def app = new TestDirApp();
component.defaultHost.attach(app);
component.start();
#curl client
curl -i --request PUT --data-binary @tmp.jpg --header Content-Type:
image/jpeg http://localhost:8181/tmp.jpg;
HTTP/1.1 201 The request has been fulfilled and resulted in a new
resource being created
Content-Length: 0
Date: Tue, 17 Nov 2009 16:23:00 GMT
Accept-Ranges: bytes
Server: Restlet-Framework/2.0m5
Connection: close
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2419969
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2420123
Re: Router in servelet not routing to correct resource
I'm not 100% sure based on that description, but try setting your second router line to: router.attach(/test1) On Oct 21, 2009, at 1:19 PM, Matt Stromske wrote: Hello, I can't figure out why my router isn't routing to the correct resource. It always seems to route to the default route. I have 2 routes: router.attachDefault(DefaultResource.class); router.attach(/gpsh/test1,TestResource.class); My servlet container mapping: url-pattern/gpsh/*/url-pattern When I attempt to go to /gpsh/test1, I end up going to the default route. Any idea how I can get the routing corrected? Thanks, Matt -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2409873 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2409935
Setting Status from the write method of a Representation
In order to support streaming writes of large ResultSets from a database, I am deferring execution of my query until the write() method of my Representations. The resource is responsible for configuring the query string and handling connection issues with the DB, but if there is a problem with the URL which results in some bad sql, and an exception is thrown inside the write method, the server always returns a 500 response even though I have subclassed StatusService and it works for exceptions thrown in the Resource. Is this expected behavior? Are there suggestions on how I can set an error status if an exception occurs in a representation? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2361698
