ServerResource doHandle logic
I'm digging through the source code of ServerResource (trying to understand
it more) and was wondering what use-case would require this logic:
if (variant instanceof Representation) {
result = (Representation) variant;
} else {
result = get(variant);
}
Is it possible to set the Variant to a Representation, thus avoiding a call
to get method?
Thanks
--
Erick Fleming
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2446616
Query string being ignored with Client.get()
I'm using JDK 1.6 build 18, with Fedora Core 8 and Restlet 2.0rc7 on
Tomcat 6.0.24.
I have a peculiar problem that started with Restlet 2.0rc7. The
Client.get() calls are ignoring the query string when called:
Client client = new Client(Protocol.HTTP);
Response response =
client.get("http://www.google.com/search?q=Supernatural";);
This URL should return the search results page, but it instead returns
the redirect to "http://www.google.com/webhp";, which is the redirect if
no search parameters (the query string) are given. Is this a known bug?
It works fine if I use the Client.get(new Reference("http",
"www.google.com", 80, "/search", "q=Supernatural", null));
Thank you!
Dustin
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2446591
Re: Restlet client connecting to server with self signed certificate
Hi Rocky,
On 10/02/2010 19:08, Rocky V wrote:
> Bruno Harbulot wrote:
>> Rocky V wrote:
>>> I am on Restlet 1.1.5 and can upgrade to 1.1.8 (last known stable version
>>> from restlet.org) if need arises.
>>> My problem is to trust all certificates for my Restlet client using HTTPS
>>> (apache common).
>>
>> I realize this is not the correct way to do it but for test purpose it's
>> really useful.
>> I have seen some other post between you and some one else mentioning that
>> it is too much of overhead
>> of putting the right SSL certificate in test environment and it should be
>> avoided.
>> And moreover, since we are testing
>> in a sort of VPN environment not exposed to external world, for my
>> purpose, I presume we are safe.
(I can't remember that discussion, but fair enough...)
>> [...]
>>
>> Reason for avoiding the option of not importing certificates is:
>> We have multiple test beds (hosts) as we call it and we may run our tests
>> against any of these test beds so it basically means, import certificates
>> for all these test beds and again if we introduce a new test bed this code
>> can break-
>> Once we are close to finalizing one single environment, we can import one
>> certificate for that
>> host and then this is not a issue but for now importing these certificates
>> is pain and I want to avoid manual step. Since, I am in automation team,
>> our goal is to have max automation.
I'll try to answer your original question below, but here is another
suggestion:
From what I understand, the system that deploys your application onto
the test beds generates self-signed certificates upon deployment, for
the purpose of testing.
In this case, you could create a test CA before deployment and, instead
of generating self-signed certificates, generate certificates signed
with this CA (because you would ship the CA's private key as part of the
deployment script, for testing purposes). To avoid clashes between
certificates, I'd use serial number 1 for the CA certificate and a
random 64-bit serial number for each generated certificate (or something
along those lines).
Since you'd know the CA certificate before deployment, you could put it
in the clients' truststore beforehand.
>> You might want to have a look at this, as a workaround using the Apache
>> HTTP client connector, for Restlet 1.
>> http://restlet.tigris.org/issues/show_bug.cgi?id=586#desc4
>>
>>
>> Do you mean to say, I can use something like this:
>> secureProtocolSocketFactory = new
>> SslContextedSecureProtocolSocketFactory(...);
>> org.apache.commons.httpclient.protocol.Protocol
>> .registerProtocol(
>>"https", new org.apache.commons.httpclient.protocol.Protocol(
>> "https", (ProtocolSocketFactory)secureProtocolSocketFactory,
>> 443));
I was referring to this SslContextedSecureProtocolSocketFactory
(although you could find other ways to do it):
http://code.google.com/p/jsslutils/wiki/ApacheHttpClientUsage
So all you'd have to do would be (with your SSLContext as below):
SslContextedSecureProtocolSocketFactory secureProtocolSocketFactory =
new SslContextedSecureProtocolSocketFactory(sc);
Protocol.registerProtocol("https", new Protocol("https",
(ProtocolSocketFactory)secureProtocolSocketFactory, 443));
(if you're using the Apache client connector, otherwise use
HttpsURLConnection as you've done.)
>> where:
>>
>> secureProtocolSocketFactory = getCustomSocketFactoryForTrustAll();
>> (To trust all server certificates for my requirement)
>>
>> private SSLSocketFactory getCustomSocketFactoryForTrustAll() {
>> SSLContext sc = null;
>> // Create a trust manager that does not validate certificate
>> chains
>> TrustManager[] trustAllCerts = new TrustManager[]{
>> new X509TrustManager() {
>> public java.security.cert.X509Certificate[]
>> getAcceptedIssuers()
>> {
>> return null;
>> }
>> public void checkClientTrusted(
>> java.security.cert.X509Certificate[] certs, String
>> authType)
>> {
>> }
>> public void checkServerTrusted(
>> java.security.cert.X509Certificate[] certs, String
>> authType)
>> {
>> }
>> }
>> };
>>
>> // Install the all-trusting trust manager
>> try {
>> sc = SSLContext.getInstance("SSL");
>> sc.init(null, trustAllCerts, new
>> java.security.SecureRandom());
>>
>> //HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
>> } catch (Exception e) {
>> }
>> return sc.getSocketFactory();
>> }
>>
>>
>> For now, it has taken me almost 4 days to find this workaround.
>> Unfortunately, I could not find
>> any post for this. I am sure this can be very usefu
RE: Problems Creating Items using the addEntity Method
Hello Jaime, I've seen your posts regarding the dataservices extension. I hope to find time this week to answer you. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2446537
RE: Routing Control to Resource class from Application
Hi, following the "first steps" applications, you should be able to get the answer to your questions : http://www.restlet.org/documentation/2.0/firstResource http://www.restlet.org/documentation/2.0/firstSteps Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2446522
RE: How to change the port the RESTlet server componenet is listening on
Hello, unless you instantiate your own component (using a restlet.xml file, or specifying a "org.restlet.component" parameter in the web.xml file), the component listens on the port defined by the servlet container. In this case, this should be transparent. Best regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2446521
RE: ERROR 404 : restlet engine or camel-restlet issue ?
Hello Bruno, regarding the dependencies, I think you can remove the "com.noelios.restlet" artifacts which reference the 1.1 branch. It should work without them. What do you mean by "and it works."? Are you able to send a post request to http://localhost:9090/poc.camel.enabler-0.0.1-SNAPSHOT and to http://127.0.0.1:9090/poc.camel.enabler-0.0.1-SNAPSHOT? Bet regards, Thierry Boileau -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2446519
How to change the port the RESTlet server componenet is listening on
Hello, I have put together an application based on the RESTlet First Resource sample code. The server component runs within Tomcat. All works fine (I can send data to the RESTlet server and it receives it. However, I would like to change the port it is listening on (it is currently listening on port 8080 by default I guess). How do I change the port the Server RESTlet componenet is listening on? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2446492
Re: Restlet client connecting to server with self signed certificate
Bruno Harbulot wrote:
>
> Hi Rocky,
>
> Rocky V wrote:
>> I am on Restlet 1.1.5 and can upgrade to 1.1.8 (last known stable version
>> from restlet.org) if need arises.
>> My problem is to trust all certificates for my Restlet client using HTTPS
>> (apache common).
>
> Am I right in understanding that you want your client to trust any
> server certificate it encounters, without prompting the user?
> If so, do you realise that this makes your connection prone to
> man-in-the-middle attacks, therefore making using SSL a bit pointless?
>
> Thanks a lot for your response, Bruno.
>
> Yes, my requirement is to trust all Server certificates and save the
> hassle of my Restlet client (using Apache commons as implementation of
> Client interface exposed by Restlet)
> try to figure out authenticity of certificate like in the Link I pasted
> above.
> I realize this is not the correct way to do it but for test purpose it's
> really useful.
> I have seen some other post between you and some one else mentioning that
> it is too much of overhead
> of putting the right SSL certificate in test environment and it should be
> avoided.
> And moreover, since we are testing
> in a sort of VPN environment not exposed to external world, for my
> purpose, I presume we are safe.
>
> This is what I want to do:
>
>
> Client client = new Client(new
> Context(),Protocol.valueOf(protocol));
>if (protocol.equalsIgnoreCase("https")) {
> // Set SSLContextFactory or something and ignore SSL
> certificates
> }
> Response response = client.handle(request);
>
>
>
> If I don't import certificates using keytool, then I would encounter
> following exceptions:
>
> com.noelios.restlet.ext.httpclient.HttpMethodCall sendRequest
> WARNING: An error occurred during the communication with the remote HTTP
> server.
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target
> at
> com.sun.net.ssl.internal.ssl.Alerts.getSSLException(Alerts.java:174)
>
> ...
>
>
> Reason for avoiding the option of not importing certificates is:
> We have multiple test beds (hosts) as we call it and we may run our tests
> against any of these test beds so it basically means, import certificates
> for all these test beds and again if we introduce a new test bed this code
> can break-
> Once we are close to finalizing one single environment, we can import one
> certificate for that
> host and then this is not a issue but for now importing these certificates
> is pain and I want to avoid manual step. Since, I am in automation team,
> our goal is to have max automation.
>
>
> (Note that the security logic for trusting any server certificate is
> very different to that for trusting any client certificate. Verification
> of the server certificate is essential.)
>
>
>> I saw this thread suggesting setting SSLContextFactory but this method is
>> only available for Restlet 2.x versions which I can't upgrade to since it
>> is
>> snapshot and my organization won't permit to upgrade to unstable
>> (supposedly) versions.
>>
>> Can you please suggest probably through snippet of code
>> how can I trust all certificates like this in Restlet client:
>> http://exampledepot.com/egs/javax.net.ssl/TrustAll.html
>>
>
> You might want to have a look at this, as a workaround using the Apache
> HTTP client connector, for Restlet 1.
> http://restlet.tigris.org/issues/show_bug.cgi?id=586#desc4
>
>
> Do you mean to say, I can use something like this:
> secureProtocolSocketFactory = new
> SslContextedSecureProtocolSocketFactory(...);
> org.apache.commons.httpclient.protocol.Protocol
>.registerProtocol(
> "https", new org.apache.commons.httpclient.protocol.Protocol(
>"https", (ProtocolSocketFactory)secureProtocolSocketFactory,
> 443));
>
>
> where:
>
> secureProtocolSocketFactory = getCustomSocketFactoryForTrustAll();
> (To trust all server certificates for my requirement)
>
> private SSLSocketFactory getCustomSocketFactoryForTrustAll() {
>SSLContext sc = null;
> // Create a trust manager that does not validate certificate
> chains
> TrustManager[] trustAllCerts = new TrustManager[]{
> new X509TrustManager() {
> public java.security.cert.X509Certificate[]
> getAcceptedIssuers()
> {
> return null;
> }
> public void checkClientTrusted(
> java.security.cert.X509Certificate[] certs, String
> authType)
> {
> }
> public void checkServerTrusted(
> java.security.cert.X509Certificate[] certs, String
> authType)
> {
> }
>
Re: M7 and TunnelService fix still not working for IE7/8 (or so it seems)
Bonjour Thierry !
I've got the snapshot, deployed it, and still got problems. Let me explain:
I get the HTML representation now, however there's a small catch. The
HTML page contains AJAX code that makes some requests in the
background to build parts of the page. One of such requests states
Accept: application/json (that is, it expects JSON back), which is
being *ignored* when the page is loaded with IE, thus breaking the
page and the application (the page does show, but with errors). With
this behaviour it's like if *all* requests coming from IE are
'converted' to the Accept header specified in accept.properties, even
those with Accept headers different from the ugly */* IE{7,8,6?}
default one.
So, I was thinking that maybe adding acceptOld: */* back to the msie
agent rules will fix this behaviour for AJAX clients that don't send a
UA string, and so use the browser's. That way, when a 'good' Accept
header (like Accept: application/json, Accept: application/zip,
Accept: whatever_good_mime_type_specified_except_the_*/*_one) is
present it is not ignored like it's being ignored now (Restlet
snapshot from yesterday)
Eagerly waiting for your answer... (bah, for the above recommended fix ;-))
BTW, I cannot remember how to do to build my own restlet, can you
please refresh my mind with pointers to the pertinent docs? Thanks.
Again, my pleasure to contribute to the already excellent Restlet framework.
On Wed, Feb 10, 2010 at 4:40 AM, Thierry Boileau
wrote:
> Bonjour Fabian,
>
> the fix is available in the current snapshot (see the changes.log):
> http://www.restlet.org/downloads/
>
> Best regards,
> Thierry Boileau
>
> Bonjour Thierry !
>
> Ah... so the problem was somewhere else :-)
>
> My pleasure to contribute to the already excellent Restlet.
>
> Any hints on when will this fix be available? or should I try (my
> socio won't like it at all...) to deploy snapshot Restlet jars?
>
> On Tue, Feb 9, 2010 at 6:24 AM, Thierry Boileau
> wrote:
>
>
> Hello Fabian,
>
> thanks for your report that helps to fix a regression.
> The value of the "accept-old" parameter is not required but due to the
> regression it was.
>
> Best regards,
> Thierry Boileau
>
>
> Hello there,
>
> Restlet 2.0M7 included a TunnelService fix for UA 'relaxed' check
> (case insensitive matching), however this doesn't seem to have fixed
> much. Whenever IE states Accept: */* (which is the default in at least
> IE7 and IE8) I'm still getting the last-defined annotated
> representation back, instead of the HTML representation like all other
> tested browsers get.
>
> Maybe this
>
> #Internet explorer
>
> agentName: msie
>
> acceptNew: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>
> is not enough, and the logic really needs:
>
> #Internet explorer
> agentName: msie
> acceptOld: */*
> acceptNew: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
>
> instead?
>
> Is there any way to add the above, more explicit, rule programatically
> to the TunnelService?
>
> A possible workaround is for me to move all @Get("html") code to
> appear last in the source, thus making HTML the preferred
> representation for when Accept: */* is specified, fixing IE in the
> process, but: 1) tying myself to M7's
> select-la...@get-as-default-when-*/*-is-specified; and 2) workaround
> instead of bugfix, so it may not work anymore later...
>
> Thanks in advance for your help.
>
>
>
>
>
--
Fabián Mandelbaum
IS Engineer
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2446422
RE: Re: Restlet and GWT 2.0
Hello Thierry, I did not succeed to run the test example you sent. I got a class not found exception on org.restlet.ext.gwt.GwtShellServletWrapper. It seems that this class is not compatible with GWT 2.0. Am I right? If so, what is the way to do? Thanks, Christophe. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2446392
Re: Restlet client connecting to server with self signed certificate
Hi Rocky, Rocky V wrote: > I am on Restlet 1.1.5 and can upgrade to 1.1.8 (last known stable version > from restlet.org) if need arises. > My problem is to trust all certificates for my Restlet client using HTTPS > (apache common). Am I right in understanding that you want your client to trust any server certificate it encounters, without prompting the user? If so, do you realise that this makes your connection prone to man-in-the-middle attacks, therefore making using SSL a bit pointless? (Note that the security logic for trusting any server certificate is very different to that for trusting any client certificate. Verification of the server certificate is essential.) > I saw this thread suggesting setting SSLContextFactory but this method is > only available for Restlet 2.x versions which I can't upgrade to since it is > snapshot and my organization won't permit to upgrade to unstable > (supposedly) versions. > > Can you please suggest probably through snippet of code > how can I trust all certificates like this in Restlet client: > http://exampledepot.com/egs/javax.net.ssl/TrustAll.html > You might want to have a look at this, as a workaround using the Apache HTTP client connector, for Restlet 1. http://restlet.tigris.org/issues/show_bug.cgi?id=586#desc4 > I have been able to import the certificate in JVM using keytool and go past > SSL exceptions but that is not a feasible option. This introduces a manual > step and I have written Restlet client code to automate Rest webservice > testing. Also, we have multiple unsigned certificates due to multiple hosts > in test environment. I guess what you're trying to do is OK in a test environment... if you make sure that code doesn't end up in production. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2446390
Re: Routing Control to Resource class from Application
Hello,
if you target the "/search" resource, the "routing" code transfers the
request/response pair to a new (and dedicated) instance of the
UserResource class.
What do you mean by "The process not goes to the resource class."? When
you want to target the "/search" URI, do you get a 404 response?
Best regards,
Thierry Boileau
> Hi,
>
> I would like to know how the control goes to the resource class after the
> code router.attach("/search",UserResource.class);
>
> I have done this in Application Class, but The process not goes to the
> resource class. What else i have to follow to map the resource class and to
> control flow to the resource class
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2446328
>
>
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2446345
Re: Extending Directory and DirectoryServerResource to have far-expiring static resources
Hello Fabian,
thanks again for your report that helps to fix an issue introduced a
long time ago (november 2007)...
As you may know, the directory relies on a client connector (generally
defined on the Component). Such client connector supports a "timeToLive"
parameter which helps to calculate the expiration date. When set to 0,
there is no expiration date (here was the bug), otherwise it represents
the life time (in seconds) of the representation.
Here is the way to set this parameter:
Client c = new Client(Protocol.FILE);
component.getClients().add(c);
c.getContext().getParameters().add("timeToLive", "0");
Having said that, this parameters applies for all directories attached
in the set of applications of your component. If you want to customize
for only one directory, you can also use a filter (placed just before
your directory) that sets the expiration date at your own convenience in
the "afterHandle" method.
Regarding the second part of your question, you should override the
"get(Variant)" method... since there is by default negotiation of
content, that is to say a variant is chosen among the available ones
according to the preferences of the clients.
Best regards,
Thierry Boileau
> Hello there,
>
> part of my application uses static (never-expiring) resources like
> images, CSS stylesheets, etc. I'm currently serving those resources
> using the Directory class, like this:
>
> Directory dir = new Directory(getContext(), "clap://system/res");
> router.attach("/res", dir);
>
> However, this sets the Expires HTTP header to the current date,
> essentialy making the representations of those resources
> non-cacheable, so the client (web browser) has to request them over
> and over again and they trip the network wire over and over again.
> This is far from optimum, even for small-sized resource
> representations.
>
> So, after reading a bit some messages on this ML, I've decided to
> extend both Directory and DirectoryServerResource like this:
>
> public class ExpirableDirectoryResource extends Directory {
>
> public ExpirableDirectoryResource(Context context, Reference
> rootLocalReference) {
> super(context, rootLocalReference);
> setTargetClass(FarExpiringDirectoryResource.class);
> }
>
> public ExpirableDirectoryResource(Context context, String rootUri) {
> this(context, new Reference(rootUri));
> }
>
> }
>
> public class FarExpiringDirectoryResource extends DirectoryServerResource {
> Calendar expiresOn;
>
> public FarExpiringDirectoryResource() {
> super();
> expiresOn = Calendar.getInstance();
> expiresOn.add(Calendar.YEAR, 1); // By default, expire 1 yr from now
> getLogger().info(String.format("+++DBG: Expiration date set to
> %s", expiresOn.getTime()));
> }
>
> @Override
> public Representation get() throws ResourceException {
> getLogger().info("+++DBG: GET on FarExpiringDirectoryResource...");
> Representation rep = super.get();
> getLogger().info(String.format("+++DBG: Should expire on %s",
> expiresOn.getTime()));
> rep.setExpirationDate(expiresOn.getTime());
> return rep;
> }
>
> }
>
> This should give my application the ability to serve static resources
> set to expire in one year, which should be enough for caching
> purposes, by simply replacing the Directory code above with:
>
> ExpirableDirectoryResource dir = new
> ExpirableDirectoryResource(getContext(), "clap://system/res");
> router.attach("/res", dir);
>
> in my application's createInboundRoot() method.
>
> However, it's not working (Restlet 2.0M7). This is what I get in the logs:
>
> 02/02/2010 13:30:59 com.calenco.resource.FarExpiringDirectoryResource
> INFO: +++DBG: Expiration date set to Wed Feb 02 13:30:59 ARST 2011
> 02/02/2010 13:30:59 org.restlet.engine.local.DirectoryServerResource doInit
> INFO: Converted target URI: clap://system/res/css/style.css
> 02/02/2010 13:30:59 org.restlet.engine.local.DirectoryServerResource
> getVariants
> INFO: Getting variants for : clap://system/res/css/style.css
> 02/02/2010 13:30:59 org.restlet.engine.log.LogFilter afterHandle
> INFO: 2010-02-02 13:30:590:0:0:0:0:0:0:1 ad...@calenco.com
> - -1 GET /res/css/style.css - 200 - 0
> 16 http://localhost:9000 Mozilla/5.0
> (X11; U; Linux x86_64; es-AR; rv:1.9.1.7) Gecko/20100106 Ubuntu/9.10
> (karmic) Firefox/3.5.7http://localhost:9000/
> 02/02/2010 13:30:59 com.calenco.resource.FarExpiringDirectoryResource
> INFO: +++DBG: Expiration date set to Wed Feb 02 13:30:59 ARST 2011
> 02/02/2010 13:30:59 org.restlet.engine.local.DirectoryServerResource doInit
> INFO: Converted target URI: clap://system/res/img/header.jpg
> 02/02/2010 13:30:59 org.restlet.engine.local.DirectoryServerResource
> getVariants
> INFO: Getting variants for : clap://system/res/img/header.jpg
> 02/02/201
Routing Control to Resource class from Application
Hi,
I would like to know how the control goes to the resource class after the code
router.attach("/search",UserResource.class);
I have done this in Application Class, but The process not goes to the
resource class. What else i have to follow to map the resource class and to
control flow to the resource class
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2446328
