Re: SSL needClientAuthentication not working
On 30/11/2011 07:12, Sean wrote: Looks like this is definitely a bug... I have tried knocking Restlet back to 2.0 and it functions as expected. 2.1RC1 and the 2.1 snapshot both won't force clientauthentication. I'd rather not switch back to 2.0 as I am using some of the new methods in 2.1.. can someone look into this one? Which connector are you using in both cases? Are you using the Simple connector for your 2.1 test? Unless it has changed since 2.0, this connector doesn't support needClientAuthentication. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2889303
Re: What is the importantce of passwords when configuring HTTPS?
On 29/11/2011 20:39, Mark Kharitonov wrote: Hi. I have followed the Restlet HTTPS guide (http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/46-restlet/213-restlet.html) to configure HTTPS. In particular, it results in a code similar to this one: parameters.add(sslContextFactory, PkixSslContextFactory.class.getName()); parameters.add(keystorePath, c:\\dev\\poc\\il-mark-lt.jks); parameters.add(keystorePassword, PASSWORD); parameters.add(keyPassword, PASSWORD); parameters.add(keystoreType, JKS); Where the PASSWORD is the password used to protect the key store as well as the used key value pair. My question is what is the importance of this password? It appears in clear text, so either it is unimportant (please, explain why) or this is a severe security hole (please, explain how to fix it). The password is there to protect access to the private keys and the keystore. In a server, you will almost certainly want to grant access to your key in a non-attended environment, i.e. let the application read the private key with the user needing to type in anything. For this, you'll need to configure your server to have access to the private key, by giving it the password for the keystore. Most servers do this (unless you go down the route of more granular access to the key, via the OS for example with the KeyChain on OSX). Apache Httpd, for example, doesn't use a password for its HTTPS configuration, but requires you not to have protected the private key with a password, which ends up being the same. In a production environment (even in a dev. environment in fact), you probably shouldn't hard-code the password in your source code, but read it from a configuration file, which would not be readable by any user other than the one running the server. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2889304
Re: An unexpected status was returned: Communication Error (1001) - sun.security.validator.ValidatorExce
Hi,
You should be able to pass your own SSLContext (similar to what you'd
use with Apache HTTP Client 4) via an SslContextFactory in the
sslContextFactory attribute, more or less like this:
final SSLContext mySslContext =
client.getContext().getAttributes().put(sslContextFactory,
new SslContextFactory() {
@Override
public SSLContext createSslContext() throws Exception {
return mySslContext;
}
@Override
public void init(SeriesParameter parameters) {
}
});
Best wishes,
Bruno.
On 01/11/10 20:51, gato wrote:
Hi to every body, I'm trying to implement a client to get resources over
https in my localhost.
My localhost web server is configured to ask authentication, and it server
one resource in this path https://localhost/resources/resource1.xml;.
Without restlet, and using httpcomponents-client-4.0.3 , the way to do it, in
other words, work with untrusted certificates is by set up a dummy SSLFactory
and a dummy TrustManager in my client application, that allows me to get
resources from https resource in my localhost.
In restlet i have been doing some tests, and I'm able to get the resource
from http protocol, my code is the next:
import java.io.IOException;
import org.restlet.Client;
import org.restlet.data.ChallengeResponse;
import org.restlet.data.ChallengeScheme;
import org.restlet.data.Method;
import org.restlet.data.Protocol;
import org.restlet.data.Request;
import org.restlet.data.Response;
import org.restlet.data.Status;
public class FirstResourceClientMain {
public static void main(String[] args) throws IOException {
// Outputting the content of a Web page
Request request = new Request(Method.GET,
http://localhost/resources/resource1.xml;);
ChallengeScheme scheme = ChallengeScheme.HTTP_BASIC;
ChallengeResponse authentication = new ChallengeResponse(scheme,
dechalar, dechalar);
request.setChallengeResponse(authentication);
Client client = new Client(Protocol.HTTP);
Response response = client.handle(request);
if (response.getStatus().isSuccess()) {
// Output the response entity on the JVM console
response.getEntity().write(System.out);
} else if (response.getStatus()
.equals(Status.CLIENT_ERROR_UNAUTHORIZED)) {
// Unauthorized access
System.out
.println(Access authorized by the server, +
check your credentials);
} else {
// Unexpected status
System.out.println(An unexpected status was returned:
+ response.getStatus());
}
}
}
and it works fine!. but when i change to
https://localhost/resources/resource1.xml;, note https
and
Client client = new Client(Protocol.HTTPS);
note Protocol.HTTPS
the next message is thrown:
An unexpected status was returned: Communication Error (1001) -
sun.security.validator.ValidatorException: PKIX path building failed:
sun.security.provider.certpath.SunCertPathBuilderException: unable to find
valid certification path to requested target
So i suppose that the problem is the trust manager, and that there must a way
to work with untrusted certificates, but i can't found an example or
doumentation about this issue.
So please, if anybody know the way to work it, i will appreciate your answers
thanks
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2677857
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2678404
Re: SAML 2.0 with Restlet
On 18/09/10 12:52, Sanchit wrote: I am developing a web-services based project which is supposed to use SAML as security token for communication with a centralized server... The centralized server maintains the roles policies associated with other entities in the ecosystem. The centralized server is not shared with us yet, I only have specification that it will maintain roles policies and expose its REST based APIs ... One doubt that I have is if Restlet SAML can alone be used in the centralized server to implement Roles Policies or if Roles Policies will necessarily be implemented using a LDAP server .. Please give your valuable suggestion , Thanking everyone in anticipation It's not really clear to me whether it's your (presumably Restlet-based) web-service you're trying to secure (and have it exchange SAML with the centralized server you don't control to get the roles and policies) or if you're wondering whether you can send SAML to and from the centralized server (which might be Restlet-based?). Both should be possible in principle. Are you using any specific SAML bindings or SAML implementation? Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2663337
Re: Embedded Jetty
Hi Roy, On 17/09/10 00:31, webp...@tigris.org wrote: Bruno, I have a standalone Restlet server and I need to support HTTPS, so I'm using jetty.xml to configure the SSLSocketConnector. I thought Jetty 7 was the current version but I don't know any reason why Jetty 6 won't work, so I'll probably just switch to that version for now. You can configure HTTPS with Restlet 1.1 in standalone mode using the Jetty, Grizzly, Simple connectors and within a servlet container using whatever the container supports. The configuration has been harmonized a bit in Restlet 2.0 (some of the parameters varied depending on the connector used with Restlet 1.1), but it was already possible set up an HTTPS server with Restlet 1.1. Before switching to Restlet 2.0, I had been running a standalone server based on Restlet 1.1 and the Jetty connector successfully (even with more complex SSL/TLS configuration based on SSLContexts, which most people don't necessarily need). Just to clarify, that wasn't running within a Jetty server. Do you have any reason to use Restlet within a servlet container as opposed to using it in standalone mode? There's nothing wrong with either, but the way SSL/TLS is configured will be different. If you're configuring SSL/TLS using SSLSocketConnector in jetty.xml and a Jetty container, whether you're using Jetty 6 or Jetty 7 shouldn't really matter as far as your Restlet is concerned. If you want to configure SSL/TLS within Restlet directly (this will only apply if you run your Restlet server directly, not within a servlet container), you can configure SSL/TLS by passing the right parameters to the Server's Context. You can find more details by clicking on the link for each specific connector from this page: http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/37-restlet.html There's an example if you want to use the Jetty connector here: http://wiki.restlet.org/docs_1.1/13-restlet/28-restlet/78-restlet.html and the list of parameters here: http://www.restlet.org/documentation/1.1/ext/com/noelios/restlet/ext/jetty/HttpsServerHelper There were minor differences in the configuration of these parameters which have been harmonized in Restlet 2.0. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2661225
Re: Embedded Jetty
Hi, On 13/09/10 02:22, webp...@tigris.org wrote: I'm attempting to use Jetty 7.1.5 with Restlet 1.1.10 however there's no connector jar included for this version of Jetty - only Jetty 6.1. So, I'm wondering is it possible to use Jetty 7? Also, I'm not sure where put jetty.xml so I can configure the server settings. It's not really clear how you're trying to use Jetty in this context: - If you're using Jetty as a Servlet container, you can use Jetty 7 (even with Restlet 1.x) and configure it with jetty.xml. You Restlet will then use the servlet connector. - If you want to use a standalone Restlet server, using Jetty as the connector library, then I think you'll have to stick with the one based on Jetty 6, as there API differences (in particualr a complete rename of the packages as far as I know). I'm not sure what the motivation for using Jetty 7 would be here (bugs?) nor what you'd want to configure via jetty.xml (as what's used is effectively just the HTTP server library of Jetty, not Jetty as a container). Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2660271
Re: restlets : communicating in SSL with tomcat
Just to clarify, if I understand well, you're using a ClientResource from within the Restlet environment running within Tomcat (so effectively, your server is a client in that respect)? How do you configure SSL on the client connector? A priori, it looks like there's something wrong with the trust store settings: either the server to which you're trying to connect has a certificate that's not trusted by the default trust store available (if you haven't specified anything), or the trust store is set up for something that doesn't have the required CA certificate. Best wishes, Bruno. On 24/08/10 12:48, Xavier Méhaut wrote: We use tomcat 5.5 with SSL, and restlet 2.0... The problem occurs when trying to access through the ClientResource setted with HTTPS protocol... regards Xavier 24 août 2010 11:56:38 org.restlet.engine.http.connector.Connection writeMessage ATTENTION: Exception while writing the message headers. 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(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.fatal(Unknown Source) at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source) at com.sun.net.ssl.internal.ssl.Handshaker.fatalSE(Unknown Source) at com.sun.net.ssl.internal.ssl.ClientHandshaker.serverCertificate(Unknown Source) at com.sun.net.ssl.internal.ssl.ClientHandshaker.processMessage(Unknown Source) at com.sun.net.ssl.internal.ssl.Handshaker.processLoop(Unknown Source) at com.sun.net.ssl.internal.ssl.Handshaker.process_record(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.readRecord(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.performInitialHandshake(Unknown Source) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.writeRecord(Unknown Source) at com.sun.net.ssl.internal.ssl.AppOutputStream.write(Unknown Source) at java.io.BufferedOutputStream.flushBuffer(Unknown Source) at java.io.BufferedOutputStream.flush(Unknown Source) at org.restlet.engine.http.connector.Connection.writeMessageHead(Connection.java:919) at org.restlet.engine.http.connector.Connection.writeMessageHead(Connection.java:933) at org.restlet.engine.http.connector.Connection.writeMessage(Connection.java:806) at org.restlet.engine.http.connector.ClientConnection.writeMessage(ClientConnection.java:297) at org.restlet.engine.http.connector.Connection.writeMessages(Connection.java:966) at org.restlet.engine.http.connector.Controller$1.run(Controller.java:81) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown Source) at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source) at java.lang.Thread.run(Unknown Source) Caused by: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.validator.PKIXValidator.doBuild(Unknown Source) at sun.security.validator.PKIXValidator.engineValidate(Unknown Source) at sun.security.validator.Validator.validate(Unknown Source) at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.validate(Unknown Source) at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source) at com.sun.net.ssl.internal.ssl.X509TrustManagerImpl.checkServerTrusted(Unknown Source) ... 19 more Caused by: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target at sun.security.provider.certpath.SunCertPathBuilder.engineBuild(Unknown Source) at java.security.cert.CertPathBuilder.build(Unknown Source) ... 25 more 2010/8/24 Bruno Harbulot bruno.harbu...@manchester.ac.uk mailto:bruno.harbu...@manchester.ac.uk Hi Xavier, If you're using Restlet within a Servlet environment, it's the container configuration that matters regarding SSL. If you have configured SSL on your Tomcat container, this should be enough. What kind of errors do you get (and which version of Restlet, just in case)? Best wishes, Bruno. On 23/08/2010 15:39, Xavier M. wrote: Hello, We use Tomcat with SSL configuration to host our restlet application. Up to now we don't succeed accessing restlets in ssl mode ; Do we need to add ssl parameters in restlets too, or is the tomcat configuration sufficient? regards Xavier -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2650640 http
Re: HTTPS connector
Hi Nicho, It looks like you need to add the com.noelios.ext.net or com.noelios.ext.httpclient jars to your classpath. Best wishes, Bruno. On 16/08/10 17:30, webp...@tigris.org wrote: I am writing HTTPs client code as below, but encountered warning message. I am using Restlet 1.1. I suspect I lost jar file in my classpath. could youi please point out whiat jar files I need to. my client code is: System.setProperty(javax.net.ssl.trustStore, c:\\storefile); System.setProperty(javax.net.ssl.trustStorePassword, changeit); System.setProperty(javax.net.ssl.keyStore, c:\\storefile); System.setProperty(javax.net.ssl.keyStorePassword, changeit); Client c = new Client(Protocol.HTTPS); Request request = new Request(Method.GET, new Reference(uri)); Response response = c.handle(request); The warning message is: WARNING: No available client connector supports the required protocols: 'HTTPS' . Please add the JAR of a matching connector to your classpath. Thanks, Nicho -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2647498 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2651194
Re: Use of ClientResource inside a server resource
Hi Xavier, In addition, if you're running the application within a servlet environment, you can configure the clients by adding this in the web.xml file: context-param param-nameorg.restlet.clients/param-name param-valueHTTP HTTPS CLAP FILE/param-value /context-param (Adapt the param-value as you need, it's a space-separated list of protocols.) Best wishes, Bruno. On 25/08/10 12:13, Xavier Méhaut wrote: Hi Fabian, We succeeded actually ; we've only forgottent to write getClients().addProtocol(Protocol.HTTP) on the server side ... thanks regards Xavier 2010/8/25 Fabian Mandelbaum fmandelb...@gmail.com mailto:fmandelb...@gmail.com Hello Xavier, yes, you can, there shouldn't be any problems with this, at least AFAIK. On Tue, Aug 24, 2010 at 6:09 AM, Xavier M. xavier.meh...@gmail.com mailto:xavier.meh...@gmail.com wrote: Hello, I would like to know if we can use a ClientResource call inside a server resource, and if not, how to do this properly? regards Xavier -- Fabián Mandelbaum IS Engineer -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2651067 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2651067 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2651196
Re: HTTPS server
Hi Nicho, The second command (parameters.add(DefaultSslContextFactory, ...)) actually doesn't do anything, since it's the sslContextFactory parameter name that is user (DefaultSslContextFactory is a possible value but not the parameter name), so this falls back to the default configuration. If you use com.noelios.restlet.ext.ssl.PkixSslContextFactory, you need to set the trust store explicitly with the old version. If you're not using client-certificates or doing anything fancy with the SSL settings, you might as well use com.noelios.restlet.util.DefaultSslContextFactory or no specific settings at all (and use the parameter names for setting the trust stores and key stores). This should have been fixed in Restlet 2.0 (and the SSL configuration has been harmonized across all connectors). Best wishes, Bruno. On 17/08/10 09:50, webp...@tigris.org wrote: Hi I want to implement https server by using Simple connector and Restlet 1.1. I put com.noelios.restlet.ext.simple_3.1.jar, org.simpleframework.jar, com.noelios.restlet.ext.ssl.jar and org.jsslutils.jar in my classpath. But I encountered a SSLContextFactory$SSLContextFactoryException when I call parameters.add(sslContextFactory, com.noelios.restlet.ext.ssl.PkixSslContextFactory); if I call parameters.add(DefaultSslContextFactory, com.noelios.restlet.ext.ssl.PkixSslContextFactory); it looks fine. anybody tell me the reason? Thanks, Nicho The Exception message: org.jsslutils.sslcontext.SSLContextFactory$SSLContextFactoryException: Exception in SSLContextFactory at org.jsslutils.sslcontext.PKIXSSLContextFactory.getPKIXParameters(PKIXSSLContextFactory.java:231) at org.jsslutils.sslcontext.PKIXSSLContextFactory.getTrustParams(PKIXSSLContextFactory.java:190) at org.jsslutils.sslcontext.PKIXSSLContextFactory.getRawTrustManagers(PKIXSSLContextFactory.java:163) at org.jsslutils.sslcontext.X509SSLContextFactory.getTrustManagers(X509SSLContextFactory.java:346) at org.jsslutils.sslcontext.SSLContextFactory.buildSSLContext(SSLContextFactory.java:256) at com.noelios.restlet.ext.ssl.PkixSslContextFactory.createSslContext(PkixSslContextFactory.java:72) at com.noelios.restlet.ext.simple.HttpsServerHelper.start(HttpsServerHelper.java:267) at org.restlet.Server.start(Server.java:383) at org.restlet.Component.startServers(Component.java:1233) at org.restlet.Component.start(Component.java:1194) at uk.ngs.ca.server.HttpsServerRun.init(HttpsServerRun.java:72) at uk.ngs.ca.server.HttpsServerRun.main(HttpsServerRun.java:86) Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors parameter must be non-empty at java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:183) at java.security.cert.PKIXParameters.init(PKIXParameters.java:140) at java.security.cert.PKIXBuilderParameters.init(PKIXBuilderParameters.java:113) at org.jsslutils.sslcontext.PKIXSSLContextFactory.getPKIXParameters(PKIXSSLContextFactory.java:215) ... 11 more -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2647748 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2651201
Re: restlets : communicating in SSL with tomcat
On 25/08/10 13:53, Xavier Méhaut wrote: Hi Bruno, Actually our architecture is the following : A PC runs a restlet server locally (withou a servlet container); the resources served by this server call themselves other restlets which are located into another restlet serveron another PC, but this restlet server one is hosted in Tomcat with SSL setted. The problem occurs when trying to call these remote restlets from the first PC. SSL is managed by tomcat and the certificate has been generated by java keygen. Ah, this makes sense. When you say the certificate has been generated by java keygen, presumably, you haven't sent the certificate request to a Certification Authority, so you're effectively using a self-signed certificate on your Tomcat server (presumably, you meant keytool instead of keygen too?). There's nothing wrong with that (although this could become an issue if you expect other clients to connect). However, for the client to be able to connect, you need to tell it to trust your server's certificate explicitly. This means that the trust store you're using on the client side needs to contain this self-signed certificate. The default trust store in Java is usually in $JAVA_HOME/lib/security/cacerts (and the default password is changeme). I wouldn't necessarily modify that file, but you can take a copy of it and import the certificate you've generated on the server into it. * On the server: 1. Find the alias you need from the keystore (otherwise, the default will be mykey: keytool -list -keystore keystore.jks You should see a list like this: Certificate fingerprint (MD5): 5B:91:3D:BB:A7:0D:04:F9:92:A0:79:0E:EA:30:45:6A the alias name, 25-Aug-2010, PrivateKeyEntry, 2. Export the certificate: keytool -exportcert -keystore keystore.jks -alias the alias name -file servercert.der (Note that you only export the certificate here, not the private key, which is not to be distributed.) * On the client: 1. It's not strictly required, but I would copy $JAVA_HOME/lib/security/cacerts to a file that doesn't affect the whole system, let's say mycacerts.jks. 2. Import the server certificate into that store: keytool -importcert -keystore mycacerts.jks -trustcacerts -file servercert.der (Optionally, use '-alias some alias name' if you want it to be easier to identity later on in the list. I'd go for the host name there, but it's just an internal indication in the store.) 3. Configure your Restlet client to use that as a trust store. If you think it's a good idea to use this as a trust store across everything that runs within that JVM, you can use the javax.net.ssl.trustStore properties. Otherwise, you can set it on a per-connector basis, using the Context parameters: parameters.add(truststorePath, pathmycacerts.jks); parameters.add(truststorePassword, password); // parameters.add(truststoreType, JKS); Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2651208
Content negotiation problem when using a specific server connector (Jetty, Simple or Netty)
Hi, The problem I described in http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2639896 was fixed in version 2.0.0 (I was using 2.0-RC4 for this test). Great! However, there's a new problem. (I'm using the same code: http://gist.github.com/496447) This works: dependencies dependency groupIdorg.restlet.jse/groupId artifactIdorg.restlet/artifactId version2.0.0/version /dependency dependency groupIdorg.restlet.jse/groupId artifactIdorg.restlet.ext.httpclient/artifactId version2.0.0/version /dependency dependency groupIdjunit/groupId artifactIdjunit/artifactId version4.4/version /dependency /dependencies As soon as I add Jetty, Simple or Netty, the tests fail. dependency groupIdorg.restlet.jse/groupId artifactIdorg.restlet.ext.jetty/artifactId version2.0.0/version /dependency The main difference I've been able to notice is that, on a GET request, with the default connector, the request's entity is an EmptyRepresentation, whereas with either Jetty, Simple or Netty, the request's entity is in InputRepresentation with isAvailable() being true. When AnnotationInfo.isCompatibleRequestEntity(...) is called as part of the automatic ServerResource.getVariants() call, the fact that there is an entity available makes it return 'false' and thus the variants are never added. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2644818
Optional authentication and ClientInfo.getAuthenticated()
Hi all,
Perhaps something that I should have noticed earlier...
Currently, an optional authenticator sets the ClientInfo to be
authenticated whether or not the authentication was successful or took
place. This is due to beforeHandle and authenticated:
@Override
protected int beforeHandle(Request request, Response response) {
if (authenticate(request, response) || isOptional()) {
return authenticated(request, response);
}
return unauthenticated(request, response);
}
//... (in authenticated)
if (request.getClientInfo() != null) {
request.getClientInfo().setAuthenticated(true);
}
I think that's not the right thing to do. I don't know if this was
intentional or if it's a bug. In my opinion, an optional authenticator
should let the request through if the authentication fail, but treat the
user as anonymous in this case.
I think ClientInfo.getAuthenticated() could be used to distinguish
between anonymous users and users who've logged on/authenticated with an
optional authenticator, which this doesn't do.
If it's a bug, I'd suggest changing beforeHandle as follows:
@Override
protected int beforeHandle(Request request, Response response) {
if (authenticate(request, response)) {
return authenticated(request, response);
} else if (isOptional()) {
return CONTINUE;
} else {
return unauthenticated(request, response);
}
}
Any thoughts?
Best wishes,
Bruno.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2643882
Re: Paging resources in GWT
On 03/08/10 14:36, Harald Pehl wrote:
In our current project we have lots of resources which return a subset of
bigger datasets. For that the paging information is provided as part of the
URL:
/some resource/{offset}/{limit}[/{sortBy}[/{sortDirection}]]
[] parts are optional. So valid URLs are
/customers/0/50
/customers/0/50/name
/customers/0/50/createdAt/desc
This works perfectly up to the fact that lots of request attributes are
occupied. For example we cannot map the URL /customers/orders/{orderId},
because it is already used for /customers/{offset}/{limit}.
Perhaps you could use the query part for these things:
/customers/?offset=50limit=20sortBy=namesortDirection=asc
I think this might help make the implementation easier on both sides.
Best wishes,
Bruno.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2642347
Re: Paging resources in GWT
On 03/08/10 15:35, Harald Pehl wrote: I thought using query parameters too, but decided against it, because it prevents caching of the resources. I'd say you're more likely to have problems with caching if you use a 'Range' header with a custom range unit than with a normal request with query parameters. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2642370
Content negotiation problem when Content-Type in a GET request
Hello,
I know it's unusual, but one of the clients I'm using (jQuery) sends a
Content-Type: application/x-www-form-urlencoded header with its GET
requests (because there's some data that's serialized in the query part
of the URI, see [1][2]).
I've looked at the HTTP specification, but I can't find where it says
it's forbidden to send that header with a GET.
The problem is that it confuses the way the content-type negotiation
works with the @Get annotation. I've put an example here
http://gist.github.com/496447.
public static class SampleResource extends ServerResource {
@Override
public void doInit() {
setNegotiated(true);
}
@Get(json)
public Representation toJson() {
return new StringRepresentation({ 'message': 'hello'
},
MediaType.APPLICATION_JSON);
}
@Get(html)
public Representation toHtml() {
return new
StringRepresentation(htmlbodyHello/body/html,
MediaType.TEXT_HTML);
}
}
The problem is that, if there's Content-Type:
application/x-www-form-urlencoded in the GET request, the content-type
negotiation fails and the default media type is used (not the one
obtained from the Accept header).
Using @Get(*:json) and @Get(*:html) instead of @Get(json) and
@Get(html), respectively, seems to fix the problem, but it seems
unnatural.
I'm just wondering if it would be sensible and/or possible to make the
content-type negotiation ignore the Content-Type header in the request
for requests with no entity, or perhaps if *: could be implied anyway
for those cases.
Best wishes,
Bruno.
[1] http://dev.jquery.com/ticket/6674
[2] http://dev.jquery.com/ticket/6811
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2639896
Re: Chaining an authorization filter after a router
On 28/06/10 16:27, Carles Barrobés wrote:
I'm trying to do the following: for URLs matching a pattern
/user/{username}/resource..., where username designates the resource's
owner, I want to grant access only if the authenticated user matches the
owner of the resource.
I created a custom authorizer that looks like:
public class UserAuthorizer extends Authorizer {
@Override
protected boolean authorize(Request request, Response response) {
User user = request.getClientInfo().getUser();
String userAuthenticated = user.getIdentifier();
String userInRequest =
(String)request.getAttributes().get(username);
return userAuthenticated.equals(userInRequest);
}
}
The problem is that the request attribute username is applied by a router,
and I haven't found a way to chain a router to my Authorizer and then this
one to another router that points to the real resources. Maybe there is
another natural way to do this in Restlet, so that the route to the resource
gets parsed (and its {parameters} added to the request) before the
authorizer can be applied.
Otherwise it looks like I have to perform the authorization step manually in
all resources.
That's not something you can do with an authorizer used as a filter. You
can still use the authorizer class, but not in a chain of filter before
the resource.
Instead, you will have to make a call to the authorizer (or write the
authorization logic) explicitly within the resource.
You don't necessarily have to rewrite everything every time. For more
flexibility, you could put this authorizer into the application context
and perhaps populate a 'owner' request attribute from the resource.
Within the resource, this would look like this:
Authorizer authorizer =
(Authorizer)getContext().getAttributes().get('the_authorizer');
getRequestAttributes().put('owner', ...);
if (authorizer.authorize(getRequest(), getResponse())) { ... }
Best wishes,
Bruno.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2626986
Re: Custom WWW-Authentication
On 23/06/2010 17:42, webp...@tigris.org wrote:
Thanks the reply.
My plan is first step client calls server by http GET, second step
server response in 401 with WWW-Authentication: PPPK realm=***,
nonce=***, opaque=***, keyid=***, version=***. In the end,
client will response back with Authorization: PPPK realm=***,
keyid=***, opaque=***, response=***.
The values of nonce, opaque, keyid and realm are created from server
and send to client for the authentication purpose, and the server
will work out client's authorization by calculating the response
value. The values of nonce and opaque are calculated by server
without relation with the definition from RFC2616/2617.
I have read your document from the link which is very helpful.
Unfortunately I am using Restlet1.1, so some methods of Restlet2.0
can not be used. Following are my part of codes:
public static ChallengeScheme MyScheme = new ChallengeScheme(This is
my scheme, PPPK);
Engine.getInstance().getRegisteredAuthentications().add(new
MyAuthHelp());
public class MyAuthHelp extends AuthenticationHelper{ public
MyAuthHelp(){ super(MyScheme, false, true); } }
But there is no formatRawRequest() and formatRawResponse() methods in
AuthenticationHelper class.
So could you please help me to work out(please note I am using v1.1,
not v2.0), and how can I put nonce, opaque and keyid in
WWW-Authentication, and put response, nonce, opaque and keyid in
Authorization?
Here is what I did a while back (with a 1.1 Milestone) for SPNEGO. It
has never been maintained and support was never intended for this draft,
but it might give you some pointers for custom ChallengeSchemes. As far
as I remember I was using Filters and not Guards.
http://github.com/harbulot/restlet-spnego-filter/
Best wishes,
Bruno.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2625756
Re: restlet on ijetty
Hi Martin, I'm sure a number of Restlet users would be interested in this (including Jerome and Thierry of course). There seems to be an open issue about it: http://restlet.tigris.org/issues/show_bug.cgi?id=1110 This may also be relevant if you're willing to contribute some code: http://www.restlet.org/community/contribute Best wishes, Bruno. On 21/05/10 14:28, Martin Svensson wrote: Hi all, I have been working on running restlet ontop of ijetty. I can let you know that it works. If the interest is there I would be happy to share how this was done. Is there anyone in particular I should contact in terms of android restlet development cheers, martin -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2611791 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2619272
Re: Unable to set Reason Phrase on successful request using Jetty
Hi Michael, On 07/06/10 15:41, Michael Rehse wrote: Using Restlet 1.1.10 and the Jetty connector (com.noelios.restlet.ext.jetty 1.1.10) deployed as a standalone application, if I set the status to 200 Foo the response comes back as 200 OK. This is not the expected behavior - is it? I have found the location of the problem - in the com.noelios.restlet.ext.jetty.JettyCall class, sendResponse method, the else reads: getConnection().getResponse().setStatus(getStatusCode()); It should read: getConnection().getResponse().setStatus(getStatusCode(), getReasonPhrase()); Should I open an issue for this? Maybe going off-topic a bit (I don't really know whether there's a bug or not). I'm just wondering why changing the reason phrase matters in your application. The HTTP spec says: http://www.w3.org/Protocols/rfc2616/rfc2616-sec6.html#sec6.1.1 - The Status-Code is intended for use by automata and the Reason-Phrase is intended for the human user. The client is not required to examine or display the Reason- Phrase. - The reason phrases listed here are only recommendations -- they MAY be replaced by local equivalents without affecting the protocol. Essentially, if a client really relies on the reason phrase, that implies it expects a different behaviour from the protocol according to that reason phrase. As such, it wouldn't be compliant with HTTP and, although it's of course not a crime, there would certainly be negative side-effects that you'd have to accept unfortunately. I think reason-phrases ought to be treated hint data targeted for people who read and debug HTTP content on the wire, nothing more. Maybe that's your use case, with a custom status code, perhaps. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2618832
Re: java client code to https service under tomcat
Hi,
On 07/06/2010 22:45, p Nut wrote:
I am trying to write a java client which calls the web service. all the
following circumstances work.
-access service using browser using http and also https. Using https, I can
access my service using a browser. I will have to accept the exception in
firefox tough.
-java client using http.
But i am not able to have my java client call the service using https
So i followed the instructions in configuring https
http://wiki.restlet.org/docs_2.0/13-restlet/27-restlet/46-restlet/213-restlet.pdf
and also followed the thread HTTP over SSL.
http://restlet.tigris.org/ds/viewMessage.do?dsMessageId=2610413dsForumId=4447
I have imported the cert into my client jvm cacerts using keytool as
mentioned in the instructions in the above link.
You don't really need to set the system property to point to this
cacerts file, since that would be the default value anyway. In addition,
I wouldn't recommend to change the JRE's cacerts by hand (at least when
experimenting), I tend to prefer to use another file. In this case you'd
have to configure it to be a trust store, which I would do via the
context's trustStore parameter rather than the global system property.
Here is the code which I am using on my client side.
System.setProperty(javax.net.ssl.trustStore,
/System/Library/Frameworks/JavaVM.framework/Versions/CurrentJDK/Home/lib/security/cacerts);
String uri = https://xyz:8443/webservice/get;;
ClientResource clientResource = new ClientResource(new Context(), new
Reference(uri));
clientResource.setProtocol(Protocol.HTTPS);
clientResource.get();
if (clientResource.getStatus().isSuccess()
clientResource.getResponseEntity().isAvailable()) {
Representation rep = clientResource.getResponseEntity();
}
I am getting the following error
at this step: clientResource.get();
Version Not Supported (505) - HTTP Version Not Supported
at org.restlet.resource.ClientResource.get(ClientResource.java:452)
Can you try it outside Tomcat as a standalone application? I've just
tried the following and it worked fine:
String uri = https://www.google.com/;;
ClientResource clientResource = new ClientResource(new Context(), new
Reference(uri));
// clientResource.setProtocol(Protocol.HTTPS);
clientResource.get();
if (clientResource.getStatus().isSuccess()
clientResource.getResponseEntity().isAvailable()) {
Representation rep = clientResource.getResponseEntity();
rep.write(System.out);
}
Would this work for you on your service?
You mentioned an error message with Firefox, is it just a warning about
the certificate not being trusted, or something else (does the server
cert have the appropriate host name too, for example)?
Best wishes,
Bruno.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2618385
Re: Using multiple Applications
On 01/06/10 21:51, jupiterroom wrote: Hi. I have an application and have implemented createInboundRoot to root the the resources I want to use. Now I have something I consider to be a new application and what to keep the routing seperate with a different implementation of createInboundRoot. I am using this bit of code: component.getDefaultHost().attach(appFoo); component.getDefaultHost().attach(appBar); However only appFoo routing seems to work. Am I doing something wrong? Can I have multiple applications? If you use 'attach' without a path, it uses an empty URI pattern (twice, so effectively one replaces the other). You should try attach with a different URI pattern for the other application: http://www.restlet.org/documentation/2.0/jse/api/org/restlet/routing/VirtualHost.html#attach(java.lang.String,%20org.restlet.Restlet) Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2616475
Re: Verifying Content-MD5
Hi Jean-Philippe,
It doesn't, and the main problem is that you need to consume the stream
for the digest to be computed. If you want to do it in a filter, you
have to store whatever your read and then put the data back into the
representation.
I've just tried with a simple example and a some text, but I think there
is a bug (*). Assuming that bug is fixed, you could have something like
that:
public class DigesterFilterDemo extends Filter {
@Override
protected int doHandle(Request request, Response response) {
Representation entity = request.getEntity();
if ((entity != null) (entity.getDigest() != null)) {
try {
DigesterRepresentation digesterRepresentation = new
DigesterRepresentation(
entity);
String text = digesterRepresentation.getText();
if (!digesterRepresentation.checkDigest()) {
response.setStatus(Status.CLIENT_ERROR_BAD_REQUEST);
return Filter.STOP;
}
request.setEntity(new StringRepresentation(text, request
.getEntity().getMediaType()));
} catch (NoSuchAlgorithmException e) {
response.setStatus(Status.SERVER_ERROR_INTERNAL, e);
return Filter.STOP;
} catch (IOException e) {
response.setStatus(Status.SERVER_ERROR_INTERNAL, e);
return Filter.STOP;
}
}
return super.doHandle(request, response);
}
}
This being said, it's probably better to check the digest in the
resource that's consuming the entity, since this temporary storage into
a 'text' variable is not suitable for all types of entities (and you
might need a large buffer).
The checkDigest() will only work once you've exhausted the stream (of
course, you could use exhaust(), but that discards the content.)
(*) Coming back to what I think is a bug:
DigesterRepresentation overrides getStream() to make it compute the
digest as the stream is being consumed.
However, if you use DigesterRepresentation.getText(), this uses
WrapperRepresentation.getWrappedRepresentation().getText(), which then
uses the wrapped representation's getStream(), not the
DigesterRepresentation's, so the digest isn't being computed when the
stream (from the wrapped representation) is being read.
Removing WrappedRepresentation.getText() fixes the problem: then
getText() uses write() (the default), which in turn uses getStream()
correctly, as overridden by DigesterRepresentation.
Best wishes,
Bruno.
On 19/05/10 19:04, Jean-Philippe Steinmetz wrote:
Hello,
I have a simple question. Does the restlet server connector verify
Content-MD5 headers by default? If not, is there a setting or filter I
can enable to make sure that it does?
Jean-Philippe
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2611379
Re: HTTP over SSL client
On 18/05/2010 18:17, webp...@tigris.org wrote: Hi Bruno, I'd like to sincerely thanks for your answer :) After following your suggestions now I set parameters in this way: org.restlet.Server https_server = new org.restlet.Server(Protocol.HTTPS, https_port); https_server.setContext(new Context()); //otherwise getContext() returns null SeriesParameter parameters = https_server.getContext().getParameters(); parameters.add(sslContextFactory, org.restlet.engine.security.DefaultSslContextFactory); parameters.add(keystorePath, KEYSTORE_PATH); parameters.add(keystorePassword, myApplication.properties.get(ADMIN_PASSWORD_KEY)); parameters.add(keyPassword, myApplication.properties.get(ADMIN_PASSWORD_KEY)); parameters.add(keystoreType, JKS); I use DefaultSslContextFactory and DSA as keyalg as suggested by you in other threads (such as http://www.mail-archive.com/discuss@restlet.tigris.org/msg07087.html ) but now the following exception gets thrown: I can't remember suggesting DSA, and the DefaultSslContextFactory is now the default anyway (so you don't need to specify it). If you created the Server after created the component, it would have a context: Server server = component.getServers().add(Protocol.HTTPS, 8183); java.io.IOException: Invalid keystore format at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:633) at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:38) at java.security.KeyStore.load(KeyStore.java:1185) at org.restlet.engine.security.DefaultSslContextFactory.createSslContext(DefaultSslContextFactory.java:198) at org.restlet.ext.simple.HttpsServerHelper.start(HttpsServerHelper.java:272) at org.restlet.Server.start(Server.java:571) at org.restlet.Component.startServers(Component.java:581) at org.restlet.Component.start(Component.java:508) I'm not sure, what's in KEYSTORE_PATH? Have you checked for example that you can read its content using keytool? keytool -list -keystore your_file.jks -storetype JKS Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2610810
Re: HTTP over SSL client
Hi, On 18/05/10 16:19, iammyr wrote: Hi everyone, I have set up a REST application, using restlet-jse-2.0snapshot to which I've added to servers: the first one supports the http protocol on port 9877, while the second one supports the https protocol on port 9873 org.restlet.Server http_server = new org.restlet.Server(Protocol.HTTP, port); org.restlet.Server https_server = new org.restlet.Server(Protocol.HTTPS, https_port); myApplication.component.getDefaultHost().attach(/appcontext, myApplication); myApplication.component.getServers().add(http_server); myApplication.component.getServers().add(https_server); then I should have up and running: http://localhost:9877/appcontext https://localhost:9873/appcontext I've also added a verifier and I provide a ping resource: Router authRouter = new Router(getContext()); authRouter.attach(/ping, PingResource.class); Cnritb_asaVerifier verifier = new Cnritb_asaVerifier(); ChallengeAuthenticator guard = new ChallengeAuthenticator(getContext(),ChallengeScheme.HTTP_BASIC, ProbesetPreprocessor); guard.setVerifier(verifier); guard.setNext(authRouter); Router router = new Router(getContext()); //attach resources which don't require authentication router.attachDefault(guard); I've created a keystore file and exported the .cer file specifying https://localhost:9873/appcontext; as both -dname and alias (-keyalg \RSA\ -sigalg \MD5withRSA\). Then I've added this .cer file to the certificates trusted by the jvm on the client side: It's not clear from this where you've actually configured the use of this keystore. It must be done with the server's context (https_server.getContext() in your case). How did you do it? In addition, it's not the URL that needs to be in the DN (-dname), it's something like: CN=the.full.host.name,OU=SomeOrganizationalUnit,O=SomeOrganization,C=CountryTwoLetters In your case, that would be at least CN=localhost (or the actual name): that's what the hostname verifier will check. keytool -import -alias https://localhost:9873/appcontext/ -file serverCerFilePath -keystore C:\Java\jdk1.6.0_20\jre\lib\security\cacerts -storepass changeit Note that you don't have to change the JRE cacerts file unless you want that to be the default in any app that runs with this JRE.) It may have to be flagged with -trustcacerts too. I've used Simple as Server connector supporting the https protocol, while as client connector I've tried either the apache httpclient or the java.net extension, but I always get an exception thrown. In particular, using the code: String registerUri = https:localhost:9873/appcontext/ping; Not sure if it's a copy/paste mistake or if it's in your actual code, but there's https:localhost is missing // in the middle. P.S. I've not created any client certificate but on the server side I've set: SeriesParameter parameters = myApplication.getContext().getParameters(); parameters.add(wantClientAuthentication, true); which should mean that the client authentication is optional Due to the way Simple works at the moment, when you're using Simple, wantClientAuthentication is always set to true anyway. In addition these settings are not meant to be done on the application's connector, but on the server's connector (along with the keystore or SSLContext settings). Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2610430
Re: Restlet - CharacterSet problem in represent method
Hi,
I'm not sure where this comes from, but it might come from the original
string that you're reading (it's not clear from your code fragment). It
looks like it could be read in UTF-8 and then written as if it was
ISO-8859-1.
You might be able to get the correct output if you make sure it's the
same character encoding as the input.
Best wishes,
Bruno.
On 11/05/10 13:33, cuaruja wrote:
Hi,
I have tried to get a xml representation of an xml structure but each time I
have an accent it doesn't work. And I have this result:
name
R�partition par webtracker
/name
public Representation represent(Variant variant) throws ResourceException {
if (MediaType.TEXT_XML.equals(variant.getMediaType())) {
try {
// CREATE dom document
DomRepresentation representation = new DomRepresentation(
MediaType.TEXT_XML);
representation.setCharacterSet(CharacterSet.ISO_8859_1);
Document d = representation.getDocument();
Element list = d.createElement(list);
d.appendChild(list);
.
d.normalizeDocument();
// Returns the XML representation of this document.
return representation;
}
catch (IOException e) {
e.printStackTrace();
}
}
return null;
}
what's wrong with this code? Could you help me?
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2609043
Re: SSL issue with Jetty, Simple
Hi Dave, On 08/05/10 17:31, David Fogel wrote: Hi Bruno- Thanks for your feedback and suggestions on this. We've sorted out a few things: 1) You were right that the Simple extension needs to have the truststorePath and truststorePassword configured in order to run. Once we added those config params in (in addition to the keystorePath, keystorePssword, and keyPassword, Simple extension works again for HTTPS. It seems like having the truststore default to the keystore, (or maybe the JRE defaults?), would be better, but at any rate we're glad to have it working again. Unless there's a bug, the current default truststore is the JRE default truststore, if nothing is specified (or whatever is passed via the -Djavax.net.ssl.truststore properties). I think this is better than having the truststore be the keystore too by default. Don't you? One of the problems with making the truststore be the keystore (as it was the case with the Simple connector before the patch between RC1 and RC3) is that you are then unable to specify another truststore (which may rightly be different to the keystore). It seems also more consistent to use the JRE default truststore as the default truststore in general. I guess the problem was triggered by the combination of (a) Simple always asking a for client certificate and (b) the default truststore being too big. Perhaps it might be worth checking that the default behaviour is the same as when you specify the JRE truststore explicitly. It would be in $JAVA_HOME/lib/security/cacerts and the default password is 'changeit'. I'd be interested in knowing how many certificates you have in yours when you get the problem. You can find this using this: keytool -list -keystore /usr/lib/jvm/java-6-sun/jre/lib/security/cacerts 2) We managed to get our StartSSL.com signed cert into a JKS-format keystore in a way that works, so now both Jetty and Simple produce warning-free HTTPS operation in our browsers. After an irritatingly large amount of time spent mucking around with keystores, we are still not sure why certain processes of importing the cert from a PKCS12 format file to a JKS result in a keystore that has all the right certs in it but which doesn't seem to understand their relationship. But we HAVE found a process that results in a correctly-configured keystore, so we're happy to move on. :-) (Specifically, I found an open-source GUI tool for working with keystores, called Portecle http://portecle.sourceforge.net/ which allowed me to first import the trustca root certs in to the pkcs12 file, and then convert the entire resulting store into JKS format. This results in a keystore which looks almost identical to one produced by first importing the signed host cert into the JKS and subsequently adding in the root certs (both keystores have the same three certs in them, with the same fingerprints, etc, but only one of them produces (when deployed in Simple, Jetty, etc) an SSL handshake which presents the full chain of trust like you mentioned in your previous message. Frustratingly, I have no idea why this is. Ah, good to know. I'll investigate what needs to be done with the JKS format. I must admit I tend to use the PKCS#12 format more because that's how I get the certificates from my CA into my browser (I think most browsers can import/export .p12, but not JKS). I've just tried with a JKS store imported from a P12 store and it worked fine (the full chain was presented), but it might depend on how that JKS store is built. If your PKCS#12 file contained the right chain, I'd suggest using that format directly. (You'd probably need to build a JKS store if you want to distribute the certificates without the private key, if your clients need to be configured with such a truststore). Since Java 6, keytool can import/export keystores. You could have made the conversion using this (or the other way around depending on which way you want to go): keytool -srckeystore file.jks -destkeystore file.p12 -destkeystoretype PKCS12 Note that: - PKCS#12 keystores use the same key for the keystore and the keys themselves. - If you export keys into a JKS store, the store will be protected with the destination password but the keys themselves will still be protected with the password with which they were imported (unless specified otherwise with -destkeypass). Alternatively, when I've had the private key in a separate file, I've been able to do this with OpenSSL: openssl pkcs12 -export -chain -in host.crt \ -CAfile cacertchain.pem -inkey host.key \ -out host.p12 Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2606825
Re: JAAS and JBoss 5.1
Hi Kevin,
This sounds good.
One of the main reasons to separate the Enroler from the Verifier was to
give the ability to have two sources of information (for example, if
verifying the credentials is done via Kerberos and fetching the roles is
done via LDAP). I don't see using the Enroler as a strict requirement,
though. You could just as well put this into the TomcatVerifier to avoid
to log on another time (you would probably have to override
verify(Request,Response) too).
Best wishes,
Bruno.
On 10/05/10 06:09, kevinpauli wrote:
My pleasure. I appreciate the elegant design of Restlet that made the
integration so straightforward.
BTW, since I posted that I also wrote a TomcatEnroler. Unfortunately, as
far as I could tell the Tomcat security api requires us to reauthenticate to
get a hold of the principal again to get his roles.
package org.restlet.ext.tomcat;
import java.util.HashSet;
import java.util.Set;
import org.apache.catalina.Context;
import org.apache.catalina.Engine;
import org.apache.catalina.Host;
import org.apache.catalina.Realm;
import org.apache.catalina.Server;
import org.apache.catalina.ServerFactory;
import org.apache.catalina.Service;
import org.apache.catalina.realm.GenericPrincipal;
import org.restlet.Application;
import org.restlet.Request;
import org.restlet.data.ClientInfo;
import org.restlet.security.Enroler;
import org.restlet.security.Role;
import org.restlet.security.User;
public class TomcatEnroler implements Enroler {
private String serviceName;
private String contextName;
public void setServiceName(String serviceName) {
this.serviceName = serviceName;
}
public void setContextName(String contextName) {
this.contextName = contextName;
}
@Override
public void enrole(ClientInfo clientInfo) {
final SetRole userRoles = findRoles(clientInfo.getUser());
for (Role role : userRoles)
clientInfo.getRoles().add(role);
}
private SetRole findRoles(User user) {
final String secret = new
String(Request.getCurrent().getChallengeResponse().getSecret());
final Server server = ServerFactory.getServer();
final Service service = server.findService(serviceName);
final Engine engine = (Engine) service.getContainer();
final Host host = (Host) engine.findChild(engine.getDefaultHost());
final Context context = (Context) host.findChild(contextName);
final Realm realm = context.getRealm();
final GenericPrincipal principal = (GenericPrincipal)
realm.authenticate(identifier, secret);
final Application application = Application.getCurrent();
final SetRole result = new HashSetRole();
for (String roleName : principal.getRoles()) {
final Role role = application.getRole(roleName);
if (role != null)
result.add(role);
}
return result;
}
}
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2606836
Re: SSL issue with Jetty, Simple
Hi Dave, On 06/05/2010 15:16, David Fogel wrote: We had previously set up SSL with a self-signed cert, generated using java keytool. This worked fine on Jetty and, until recently, with the Simple connector, which had some hanging issues a few revisions ago (but which may have been fixed, we're not sure. overall we'd prefer to get back to using the simple connector). Have you tried the Simple connector since 2.0-RC2? It should incorporate the fix discussed in the thread you started at the end of March http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2464621 (a newer release of the Simple library). Our configuration involved something like this: SeriesParameter params = s.getServers().add(Protocol.HTTPS, 8443) .getContext().getParameters(); params.add(keystorePath, path/to/keystore.jks); params.add(keystorePassword, secret); params.add(keyPassword, secret); This looks correct (although you might need to configure a truststore too if you're using the Simple connector, see below). We recently decided to acquire a real CA-signed cert, which we got from StartSSL.com. I built up a keystore which imports their root certs and the cert they signed for us. Doing a keytool -list command shows something like this: Keystore type: JKS Keystore provider: SUN Your keystore contains 3 entries startcom.ca.sub, Apr 26, 2010, trustedCertEntry, Certificate fingerprint (MD5): 30:B0:5A:F7:B2:F4:BE:0C:28:67:15:EA:CC:5B:24:20 startcom.ca, Apr 26, 2010, trustedCertEntry, Certificate fingerprint (MD5): 22:4D:8F:8A:FC:F7:35:C2:BB:57:34:90:7B:8B:22:16 startcom pfx certificate, Apr 26, 2010, PrivateKeyEntry, Certificate fingerprint (MD5): 15:F4:A5:34:C6:B1:DE:BE:BF:4E:5D:83:BA:97:89:1E Here is what we experience now: With Jetty: - everything seems to work great in our Safari, Chrome, and IE browsers, in that HTTPS works and the browser doesn't complain. - Firefox complains that the cert is Untrusted What does Firefox say in detail? Usually, you can get the certificate and it will tell you what's wrong with it (on the first dialog after the warning page, the one where you can get the cert and choose to accept/refuse it). Maybe the StartSSL CA certificates aren't installed in this Firefox (it may also vary depending on the distribution on Linux for example). I'm afraid I haven't tried StartSSL. The ability for a CA to be trusted by a browser often has nothing to do with the browser or its technical capabilities, but is rather an administrative, legal or political issue as to which CAs get bundled with the browser's installer. With Simple extension, and using the same configuration: - no access at all via HTTPS. no response or log message at all on the server at startup or on request Perhaps try setting the truststore to use the keystore too? params.add(truststorePath, path/to/keystore.jks); params.add(truststorePassword, secret); Otherwise, you might run into a similar problem as in this thread: http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2599797 (This is due to the fact that Simple always ask for a client-certificate at the moment). Anyone else successfully serving up CA-signed HTTPS using Jetty or Simple? And why doesn't the default connector do HTTPS? I have. Admittedly, mostly with the UK e-Science CA: its certificates aren't bundled by default with browsers, but that's an admin/trust problem, not a technical one. Also, I've never been clear on what the org.restlet.ext.ssl module is for- will it add HTTPS support to the default restlet connector? The SSL extension is mostly useful if you want advanced SSLContext settings (e.g. specific client certificate settings or non-default trust models such as those used with FOAF+SSL or grid computing). You probably don't need it if you're not using client certificates at all. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2604285
Re: SSL issue with Jetty, Simple
Hi Dave, On 06/05/2010 17:07, David Fogel wrote: What does Firefox say in detail? Usually, you can get the certificate and it will tell you what's wrong with it (on the first dialog after the warning page, the one where you can get the cert and choose to accept/refuse it). firefox is saying: local.mydomain.org:8083 uses an invalid security certificate. The certificate is not trusted because the issuer certificate is unknown. (Error code: sec_error_unknown_issuer) Maybe the StartSSL CA certificates aren't installed in this Firefox (it may also vary depending on the distribution on Linux for example). I'm afraid I haven't tried StartSSL. The ability for a CA to be trusted by a browser often has nothing to do with the browser or its technical capabilities, but is rather an administrative, legal or political issue as to which CAs get bundled with the browser's installer. Looking at firefox's list of certificate authorities, I see the various startcom certs. So as far as I understand it, it should work. From what I've heard elsewhere, firefox differs from other browsers in part by using it's own list of trusted root certs, instead of the host system's built-in list. But either way, the certs seem to be there. I'm pretty sure that the startcom/startssl certs are widely enough used that they're trusted by all browsers and operating systems. They also specifically claim this on their site. So I feel it is more likely that I've misconfigured the keystore or misconfigured restlet/jetty/etc. One way to diagnose what certificates are configured is to use OpenSSL (often pre-installed on Linux/OSX): echo | openssl s_client -showcerts -connect local.mydomain.org:8083 The command above isn't configured with any trusted certificate, so it will most likely say verify error:num=19:self signed certificate in certificate chain, which you can ignore. The important part is that it should show the certificate chain after: Certificate chain 0 s:/C=UK/O=eScience/OU=Manchester/L=MC/CN=.../emailAddress=... i:/C=UK/O=eScienceCA/OU=Authority/CN=UK e-Science CA -BEGIN CERTIFICATE- ... XxdhCHujMWxwSLQq -END CERTIFICATE- 1 s:/C=UK/O=eScienceCA/OU=Authority/CN=UK e-Science CA i:/C=UK/O=eScienceRoot/OU=Authority/CN=UK e-Science Root -BEGIN CERTIFICATE- ... dZwURrmRAbx676x3Ef2po8s= -END CERTIFICATE- 2 s:/C=UK/O=eScienceRoot/OU=Authority/CN=UK e-Science Root i:/C=UK/O=eScienceRoot/OU=Authority/CN=UK e-Science Root -BEGIN CERTIFICATE- ... -END CERTIFICATE- --- Server certificate subject=/C=UK/O=eScience/OU=Manchester/L=MC/CN=.../emailAddress=... issuer=/C=UK/O=eScienceCA/OU=Authority/CN=UK e-Science CA Here, cert 0 (the server's) was issued by 1, which was issued by 2. I didn't have anything explicit to do to get the server to serve the full chain. I'm only using a keystore that contains these certs + the private key for the server's cert, with extra config. (My keystore is in PKCS#12 format, but that really shouldn't make any difference, your JKS seemed fine, provided it contains the right intermediate certs.) What you should have is a chain that's not broken and that builds up to at least something that's in Firefox's trusted CA certificates. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2604404
Re: SSL modifications since 2.0 RC 1 ?
Hi Nicolas, On 03/05/2010 15:09, Nicolas Rinaudo wrote: Hi Bruno, You certainly put a lot of effort into that ! I have to admit that some of it went over my head - you obviously are a bit of an expert on the matter, which I'm not. If I understand you properly, the problem isn't Restlet, Safari, or even Java specific - it's a generic flaw (?) in client certificates management ? Yes, it looks like it. I guess few services that rely on client certificates reach that sort number of CAs they'd trust w.r.t. client certificates. Usually, you'd tend to configure your server to accept certificates for a smaller number of CAs, I think. 120+ is rather large and probably unusual. Which means that in my very specific, very selfish case, I should disable client certificate requests to make the problem go away. Which also means getting rid of the Simple connector, since this is hardcoded and can't be modified. Is that a fair summary, or did I misunderstand you even more badly than I thought ? There are a few options: 1. Send an e-mail on the Simple framework list to request the feature. I'm afraid I don't have any spare time to do it, but the maintainer of Simple doesn't seem to be against the idea. Of course, that could take a bit of time to be implemented, but I guess it's worth asking. (Once it's in Simple, in a version that's then integrated in Restlet, adapting the connector should be straightforward.) 2. Use another connector and don't enable client certificate negotiation (the default in the other Restlet connectors). 3. Keep using Simple (with optional client-certificate negotiation), but use a smaller truststore (Note that you can't use an empty truststore.) The easy way to do this would be to use your keystore as a truststore too (configuring the truststore* properties in addition to the keystore* properties to use the same corresponding values). You probably won't have more than your server certificate or perhaps the CA certificates in its chain, so you won't get anywhere near the limit. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2602692
Re: SSL modifications since 2.0 RC 1 ?
Hi Nicolas, On 28/04/2010 12:55, Nicolas Rinaudo wrote: This might be an important bit of information. After running a few more tests, I realised that Safari would: - fail ignoring certificates if the server is running on OS X. - succeed in ignoring certificates if the server is running on Debian Lenny (5.0) This might be an OS X only issue after all. I've looked a bit more into this issue, and it doesn't seem OSX-specific (on the server side) unfortunately. It's not even specific to self-signed certificates (I've tried with a trusted cert), the Simple connector or Restlet. I've managed to reproduce it with a basic Jetty server [1] running with the Sun JVM on a Linux box. It has similar symptoms to the buffer issue we had a few weeks ago [2], but I don't know whether it's a Java or a Safari problem at this stage. It appears with Simple, because Simple always requests (wants) a client certificate. It also happens with Jetty if it's configured to do so. To (try to) keep it short, when a TLS server requests a client certificate during the handshake, and extra TLS message is sent (CertificateRequest), which contains a list of the names of the CAs from which the server would be willing to accept client certificates. In Java, this list is automatically populated by the default SSLContext with the list of names corresponding to the certificates held in the truststore. The more certificates in the truststore, the longer the list, and thus the bigger the packet. On the current OSX 10.6, the default truststore [3] seems to have about 160 certificates, whereas on an Ubuntu 9.10 (Sun JVM) the default trust store contains about 75. When I use the Mac's truststore on the Linux box, this fails too. When I use a smaller truststore on the Mac, it works there. I've tried to debug the SSL handshake on the Java side and it looks like it works fine, internally; however, when looking at the packets with WireShark, not everything sent by the server according to the Java debugging logs seems to be effectively sent. I suspect this is a buffer size problem similar to [2], although in this case, it happens with other servers, using NIO or BIO. A workaround would be to specify a smaller truststore or to turn off the optional client-certificate authentication. Best wishes, Bruno. [1] http://gist.github.com/385281 [2] http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2465481 [3] /Library/Java/Home/lib/security/cacerts [4] /usr/lib/jvm/java-6-sun/jre/lib/security/cacerts -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2599797
Re: SSL modifications since 2.0 RC 1 ?
Hi Nicolas,
Nicolas Rinaudo wrote:
First, thanks for taking the time to look into this, I really appreciate it.
Now, to answer your post.
2. By default, the SSLContext (on the server connectors) is created by
the DefaultSslContextFactory, which follows the defaults of the JSSE Ref
guide by default. It will use javax.net.ssl.keyStore,
javax.net.ssl.trustStore and related properties if specified, otherwise,
the keystore is unspecified (you'd always have to configure it anyway)
and the truststore is based on the CA certificates bundled with the JRE.
I'm not sure I follow. Do you mean that in order to configure my server side
keystore, I need to use the corresponding system properties ?
What I'm doing is initialising the connector with parameters initialised as
follows:
parameters = new VectorParameter();
parameters.add(new Parameter(keystorePath, keystorePath));
parameters.add(new Parameter(keystorePassword, keystorePassword));
parameters.add(new Parameter(keyPassword, keyPassword));
Has that changed ?
That hasn't changed. I don't usually use vectors, but change the
existing parameters instead. I guess it's the same end-result.
SeriesParameter parameters = context.getParameters();
parameters.add(keystorePath, ...);
parameters.add(keystorePassword, ...);
parameters.add(keyPassword, ...);
parameters.add(truststorePath, ...);
parameters.add(truststorePassword, ...);
What I meant when I was talking about the system properties is that the
DefaultSslContextFactory works as follows (it's initialised with the
parameters and falls back to system properties or default values):
- For the keystore:
1. If 'keystorePath' is specified in the connector's context
parameters (as above), those values are used.
2. Failing (1), if the 'javax.net.ssl.keyStore' system property is used.
3. Failing (1) and (2): there's no default value. If you want to use
a keystore, you must specify it.
- For the truststore:
1. If 'truststorePath' is specified in the connector's context
parameters (as above), those values are used.
2. Failing (1), if the 'javax.net.ssl.trustStore' system property is
used.
3. Failing (1) and (2): the JVM's default value is used. On the Sun
JVM, that store is in $JAVA_HOME/security/cacerts.
If you're only setting the keystore and not the truststore, the JVM
default value will be used. This should be fine for your server, since
you're not using client certificates.
In addition, the Simple connector is set up to ask for an optional
client certificate (that's hard-coded in Simple). If the client sends
one it doesn't like, this would cause the connection to break.
Right, that might explain things.
On the client side, I'm using the internal connector without any specific
configuration, except for the following code executed in our test cases:
SSLContext sc = SSLContext.getInstance(SSL);
sc.init(null, new TrustManager[] {new X509TrustManager() {
public X509Certificate[] getAcceptedIssuers() {return null;}
public void checkServerTrusted(X509Certificate[] certs, String authType)
throws CertificateException {}
public void checkClientTrusted(X509Certificate[] certs, String authType)
throws CertificateException {}
}}, new SecureRandom());
HttpsURLConnection.setDefaultSSLSocketFactory(sc.getSocketFactory());
HttpsURLConnection.setDefaultHostnameVerifier(new HostnameVerifier() {
public boolean verify(String urlHostName, SSLSession session) {return
true;}
});
I don't really see how that could result in the client sending an odd
certificate, but I'm a bit out of my depths here and I might very well have
overlooked something.
Indeed, since your array of KeyManagers is null, that SSLContext won't
provide a client certificate to send (so that's not the problem).
I think the problem comes from the fact you're setting the
HttpsURLConnection.setDefaultSSLSocketFactory directly. The Restlet Net
connectors doesn't use the java.net default SSLSocketFactory at all now.
To harmonise the configuration, all connectors use the Restlet
SslContextFactory (and implicitly its DefaultSslContextFactory if none
is specified explicitly, with the behaviour described above).
This change was made between RC1 and RC2, so that's probably why you get
the problem. The benefits of this change are that you can now use the
same settings whether you're using the Net or the Apache HttpClient
connector (whereas the code you had above was specific to the Net
connector and affecting all the HttpsURLConnections); it also makes the
configuration of the client connectors similar to that of the server
connectors (i.e. via the 'sslContextFactory' attribute).
To fix this, here is how it can be done on the client side (based on
your code):
final SSLContext sc = SSLContext.getInstance(SSL);
sc.init(null, new TrustManager[] {new X509TrustManager() {
public X509Certificate[] getAcceptedIssuers() {return null;}
Re: SSL modifications since 2.0 RC 1 ?
Hi Nicolas, Nicolas Rinaudo wrote: Hey, We've just upgraded form RC 1 to RC 3 (we skipped RC 2 due to blocking issues), and there appears to have been some changes in the way SSL keystores are managed - our test self-signed certificate that worked perfectly with RC 1 now has issues with RC 3. The behaviour is a bit odd: - Firefox accepts it after having been told to ignore it. - Safari refuses it, whether or not it has been told to ignore it. Could you clarify what you mean by accept/ignore? I'm not sure what this means in the context of Firefox/Safari. In Firefox, all I tend to see is 'Get me out of here!', 'I understand the risks' - 'Add exception' (and perhaps 'Permanently store this exception'). (Is it Safari on Mac or Windows, btw?) - curl accepts it with the -k flag That should always work indeed, since it doesn't verify the certificate of the server at all. - connecting using an RC 1 powered Java client works, an RC 3 powered one fails. Are you using client-certificates? Could you explain what configuration you use for the client? (In particular w.r.t the trust store?) From what I've found, it appears that there were some modifications in keystore management, but the only thing I could find was SSL keystores configuration was adjusted for simplicity purpose in the RC 2 release notes. Is there a list of what precisely these changes are I can find somewhere ? I don't know whether that's useful, but: - we're using the Simple web server. - querying our server with curl, the only differences I could find between RC 1 and RC 3 were: SSL connection using EDH-RSA-DES-CBC3-SHA (RC 1) and SSL connection using DHE-RSA-AES256-SHA (RC 3). One of the changes that was made was that the Simple connector was using the keystore for both the keystore and the truststore. Now, the truststore is the default JRE truststore unless explicitly specified (which is more correct), like it was the case for the other connectors (Jetty, Grizzly). The keystore is what has the private key and the certificate that are local (server cert+priv. key on the server and client cert+priv. key on the client). The truststore is the repository of trust anchors used to evaluate trust in the remote certificate (for example, you would have to put your server's self-signed cert into the client's truststore for it to be trusted by the client). I'm not sure where the change in cipher suites comes from (EDH-RSA-DES-CBC3-SHA/DHE-RSA-AES256-SHA), but it shouldn't affect how the certificates are trusted. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2595939
Re: SSL modifications since 2.0 RC 1 ?
Nicolas Rinaudo wrote: Could you clarify what you mean by accept/ignore? I'm not sure what this means in the context of Firefox/Safari. Right, sorry, that wasn't very clear. Accept: the browser will load the page without complaint. Refuse: the browser will fail to load the page with an error message such as Safari can’t establish a secure connection to the server 'localhost'. Ignore: instructing the browser to ignore the fact that the certificate is self-signed - adding an exception in Firefox, for example. All the tests I've described before are on OS X. OK, from what you're saying, Firefox and Curl work as expected, Safari doesn't and your Restlet 2.0-RC3 based client doesn't either. (I'll leave Safari aside for the moment, as I don't have an OSX machine with me right now.) The main changes that were made regarding SSL between RC1 and RC3 are: 1. Clients no longer use $HOME/.keystore as their keystore by default (it has to be specified if the client wants to use a client-certificate). 2. By default, the SSLContext (on the server connectors) is created by the DefaultSslContextFactory, which follows the defaults of the JSSE Ref guide by default. It will use javax.net.ssl.keyStore, javax.net.ssl.trustStore and related properties if specified, otherwise, the keystore is unspecified (you'd always have to configure it anyway) and the truststore is based on the CA certificates bundled with the JRE. This second change shouldn't break the existing connectors, since it's how they were initialised anyway (except that now, the code is in one place instead of copied across into each connector). It does change the way the Simple connector works, because the simple connector was using the keystore settings for the truststore too. In addition, the Simple connector is set up to ask for an optional client certificate (that's hard-coded in Simple). If the client sends one it doesn't like, this would cause the connection to break. are you using client-certificates? Could you explain what configuration you use for the client? (In particular w.r.t the trust store?) I'm not using client-certificates, no. To be honest, I've no idea what a trust store is. The only thing I can think of that might be related to that is the code we use in our tests to disable SSL certificate validation: - set the default host name verifier to an instance that will accept anything. - set the trust manager to a pass-through implementation. The trust store is the store used by most trust managers (in particular the default one) to load its trusted certificates from. If your client sets its own trust manager as a pass-through implementation, it's likely not to be used. I'd be happy to post the code if you need me to. That could help indeed. It might have to do with how this trust manager is written and passed to the connectors. for example, you would have to put your server's self-signed cert into the client's truststore for it to be trusted by the client). This confuses me a bit - I thought that's exactly what I did when I told Safari to add the certificate to the list of trusted certificates. Once I've done that, however, Safari still refuses to load pages. I'm not sure where the change in cipher suites comes from, but it shouldn't affect how the certificates are trusted. What confuses me is that even using the enabledCipherSuites and disabledCipherSuites, I can't change these. Are these instructions ignored in the new version ? They're not, but not all connectors support them in the same way unfortunately (in some you can enable, in some you can disable). There's little we can do about it, since it depends on the underlying library support (I got a patch in for Jetty a few weeks ago, but I'm not sure it's made it into the release yet). Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2595999
Re: HTTPS / SSL not working after updating to trunk
Hi Dave, On 25/03/2010 21:47, David Fogel wrote: Hi Bruno- So, I got Jetty working as the connector, and yes, it does seem to work fine with our previously discussed HTTPS configuration. So that can hold us for now, but we do eventually want to use the Simple connector. Incidentally, based on recent postings to the simpleframework support list, it appears that Niall (the author of Simple) plans to release a bug-fix version in the next few days for some problem having to do with a potential endless loop writing to a socket. So I wonder if this could be part of the issue... I think I've tracked down the problem to be a Simple bug: the output buffer used during the TLS handshake is too small to send a big list of CA certificates (since Simple always requests a client certificate, it sends the list of CAs it's willing to accept within the TLS CertificateRequest message: this list is longer with the default trust store bundled with the JRE and used when nothing is specified). More on this here: http://sourceforge.net/mailarchive/message.php?msg_name=4BACBFF1.7090108%40manchester.ac.uk Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2465481
Re: HTTPS / SSL not working after updating to trunk
Hi,
Sorry, that's probably due to a patch I submitted a few weeks ago and
that was put in the trunk a couple of days ago.
The aim was to consolidate the SSL settings to have them in one place,
but it seems that there was a line missing unfortunately.
Here is a patch:
diff --git
a/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
b/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
index 6ac6b93..36c7c80 100644
--- a/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
+++ b/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
@@ -218,6 +218,7 @@ public class SslUtils {
if (result == null) {
result = new DefaultSslContextFactory();
+result.init(helper.getHelpedParameters());
}
return result;
I've tried it with the Jetty connector and it fixes the problem. It
doesn't seem to work so well with the Simple connector, I'm looking into it.
Best wishes,
Bruno.
On 25/03/2010 03:09, David Fogel wrote:
Hi all-
We recently updated our restlet libraries to the current trunk
(specifically SVN revision 6394, which I imagine is roughly equivalent
to the recent 2.0 RC1 release). We were previously working with a
build from SVN 5929, from roughly late December. Now we're dealing
with the fallout. For some reason this often seems to involve
problems that are hard to resolve, or have subtle or hard to reproduce
causes. Probably because of the fast pace of improvements in restlet
development
Our previous problem, which I posted earlier had to do with the
built-in Client connector waiting/suspended on a latch that never
returns. We are temporarily avoiding that by using the HttpClient 4
extension, which doesn't have this problem for us, but we'd prefer I
think to use the built-in ones.
The next thing we discovered was broken is HTTPS access for our web
app. We now get a The connection was reset message in the browser
(in this case it is firefox), when we try to GET a resource at the
HTTPS port, and no request is logged by restlet. This had been
working fine for use with the december build.
Our configuration for the Component protocols is (roughly) as follows:
Component c = new Component();
c.getServers().add(Protocol.HTTP, 8080);
SeriesParameter params = c.getServers().add(Protocol.HTTPS,
8443).getContext().getParameters();
params.add(keystorePath,
/an/absolute/path/to/the/keystore/localhost.jks);
params.add(keystorePassword, not actually our password);
params.add(keyPassword, another password);
I'm not sure if it makes a difference, but we're using the
simpleframework server connectors. I tried simpleversion 4.1.17 (which
was working before and now doesn't) as well as the slightly newer
4.1.19 build.
So, did something break in recent versions? or were we doing
something wrong in the first place that just happened to work?
I will also note that the documentation is VERY CONFUSING regarding
configuring HTTPS/SSL in the userguide. There is only one example,
and that example specifically uses the org.restlet.ext.ssl extension
along with a SSLContextFactory set to be
org.restlet.ext.ssl.PkixSslContextFactory. I think that an example
which explains the option of using the DefaultSslContextFactory would
be appropriate, along with some explanation about which situations are
better handled by the extension. Given that configuring one's server
for HTTPS must be an extremely common task, it seems like there should
be more about this- as it stands there seems to be more docs for
setting up client cert authentication etc, which is probably less
common.
Thanks,
-Dave Fogel
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2464621
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2464831
Re: HTTPS / SSL not working after updating to trunk
Hi,
I've put a patch for this in
http://restlet.tigris.org/issues/show_bug.cgi?id=977
I've tried it locally with the Simple, Jetty and Grizzly connectors (and
the test cases pass).
This patch also removes the explicit use of DefaultSslContextFactory in
the test case, to assume we're testing the simple configuration case.
The keyPassword is also the keystorePassword if absent (rather than
by default, which never works).
Since you're working from the SVN trunk, I suppose you might be able to
apply the patch as well. Please let us know if it fixes the problem you had.
You're right regarding the documentation, it could be clearer. The basic
configuration should be like this (that's what you had):
Component component = new Component();
Server server = component.getServers().add(Protocol.HTTPS, 8443);
SeriesParameter params = server.getContext().getParameters();
params.add(keystorePath, /.../.../...);
params.add(keystoreType, PKCS12); // KeyStore.getDefaultType() by
default (JKS).
params.add(keystorePassword, testtest);
params.add(keyPassword, testtest);
The use of SslContextFactory is for people who want to pass more
customised SSLContexts.
Best wishes,
Bruno.
Bruno Harbulot wrote:
Hi,
Sorry, that's probably due to a patch I submitted a few weeks ago and
that was put in the trunk a couple of days ago.
The aim was to consolidate the SSL settings to have them in one place,
but it seems that there was a line missing unfortunately.
Here is a patch:
diff --git
a/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
b/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
index 6ac6b93..36c7c80 100644
--- a/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
+++ b/modules/org.restlet/src/org/restlet/engine/security/SslUtils.java
@@ -218,6 +218,7 @@ public class SslUtils {
if (result == null) {
result = new DefaultSslContextFactory();
+result.init(helper.getHelpedParameters());
}
return result;
I've tried it with the Jetty connector and it fixes the problem. It
doesn't seem to work so well with the Simple connector, I'm looking into it.
Best wishes,
Bruno.
On 25/03/2010 03:09, David Fogel wrote:
Hi all-
We recently updated our restlet libraries to the current trunk
(specifically SVN revision 6394, which I imagine is roughly equivalent
to the recent 2.0 RC1 release). We were previously working with a
build from SVN 5929, from roughly late December. Now we're dealing
with the fallout. For some reason this often seems to involve
problems that are hard to resolve, or have subtle or hard to reproduce
causes. Probably because of the fast pace of improvements in restlet
development
Our previous problem, which I posted earlier had to do with the
built-in Client connector waiting/suspended on a latch that never
returns. We are temporarily avoiding that by using the HttpClient 4
extension, which doesn't have this problem for us, but we'd prefer I
think to use the built-in ones.
The next thing we discovered was broken is HTTPS access for our web
app. We now get a The connection was reset message in the browser
(in this case it is firefox), when we try to GET a resource at the
HTTPS port, and no request is logged by restlet. This had been
working fine for use with the december build.
Our configuration for the Component protocols is (roughly) as follows:
Component c = new Component();
c.getServers().add(Protocol.HTTP, 8080);
SeriesParameter params = c.getServers().add(Protocol.HTTPS,
8443).getContext().getParameters();
params.add(keystorePath,
/an/absolute/path/to/the/keystore/localhost.jks);
params.add(keystorePassword, not actually our password);
params.add(keyPassword, another password);
I'm not sure if it makes a difference, but we're using the
simpleframework server connectors. I tried simpleversion 4.1.17 (which
was working before and now doesn't) as well as the slightly newer
4.1.19 build.
So, did something break in recent versions? or were we doing
something wrong in the first place that just happened to work?
I will also note that the documentation is VERY CONFUSING regarding
configuring HTTPS/SSL in the userguide. There is only one example,
and that example specifically uses the org.restlet.ext.ssl extension
along with a SSLContextFactory set to be
org.restlet.ext.ssl.PkixSslContextFactory. I think that an example
which explains the option of using the DefaultSslContextFactory would
be appropriate, along with some explanation about which situations are
better handled by the extension. Given that configuring one's server
for HTTPS must be an extremely common task, it seems like there should
be more about this- as it stands there seems to be more docs for
setting up client cert authentication etc, which is probably less
common.
Thanks,
-Dave Fogel
Re: HTTPS / SSL not working after updating to trunk
Hi David, David Fogel wrote: Hi Bruno, Jerome- Thanks for taking a look at this! I've just updated to the latest in trunk (SVN revision 6407). Unfortunately, the fix doesn't seem to be working- in fact now what I'm seeing is that the connection is never made from the client, but now my server starts using both CPU cores (up to %170 percent of my machine) just spinning away, causing the fans to blow. Nothing shows up in the logs. I'll test further, but so far still not working for me. Could you try with another connector, just in case (Jetty or Grizzly)? I had noticed a connection problem (once) when writing the patch this morning and testing it at the same time with the Simple connector, but I haven't had the problem since. (I'll try again on another machine.) Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2465026
Re: HTTPS / SSL not working after updating to trunk
To give you a bit more details, just in case you manage to see a bit
more what's happening on your side, the patch that was put in the trunk
today (r6407) was clearly due to the fact I had omitted a very important
line: the one that passes the parameters to the factory:
if (result == null) {
result = new DefaultSslContextFactory();
+result.init(helper.getHelpedParameters());
}
Once that was fixed, the SSLContexts appear to be initialised as
expected (I've even run this with the debugger within Eclipse).
The other patch that affected the SSLContext was r6391. It was
essentially moving the code duplicated in the DefaultSslContextFactory
and in the default connectors into the DefaultSslContextFactory anyway:
@@ -267,37 +269,7 @@ public class HttpsServerHelper extends
SimpleServerHelper {
// Initialize the SSL context
final SslContextFactory sslContextFactory = SslUtils
.getSslContextFactory(this);
-SSLContext sslContext;
-/*
- * If an SslContextFactory has been set up, its settings take
priority
- * over the other parameters (which are otherwise used to build and
- * initialize an SSLContext).
- */
-if (sslContextFactory == null) {
-final KeyStore keyStore =
KeyStore.getInstance(getKeystoreType());
-final FileInputStream fis = getKeystorePath() == null ? null
-: new FileInputStream(getKeystorePath());
-final char[] password = getKeystorePassword() == null ? null
-: getKeystorePassword().toCharArray();
-keyStore.load(fis, password);
-if (fis != null) {
-fis.close();
-}
-
-final KeyManagerFactory keyManagerFactory = KeyManagerFactory
-.getInstance(getCertAlgorithm());
-keyManagerFactory.init(keyStore,
getKeyPassword().toCharArray());
-
-final TrustManagerFactory trustManagerFactory =
TrustManagerFactory
-.getInstance(getCertAlgorithm());
-trustManagerFactory.init(keyStore);
-
-sslContext = SSLContext.getInstance(getSslProtocol());
-sslContext.init(keyManagerFactory.getKeyManagers(),
-trustManagerFactory.getTrustManagers(), null);
-} else {
-sslContext = sslContextFactory.createSslContext();
-}
+SSLContext sslContext = sslContextFactory.createSslContext();
Considering that the SslContextFactory seems to behave as expected, I'm
not quite sure the problem comes from there.
While I wasn't noticing the problem on my Linux box, I'm noticing a
similar problem on my Mac: the connection just hangs when connecting to
my test app when using the Simple connector (not with Jetty/Grizzly).
I think the only difference then, from the previous code, is that the
previous code used to initialise the trustmanager with the same keystore
as the keymanager.
In fact, this solves the problem, partly. If I use the same settings for
the trust manager in this test app, it now works on my Mac:
params.add(truststorePath, ...);
params.add(truststorePassword, testtest);
This shouldn't be required. I've had a brief look at the SimpleFramework
code itself, but I can't spot anything obvious.
If you could try to set the truststore like your keystore, perhaps it
would fix your problem in the short term.
Best wishes,
Bruno.
On 25/03/2010 18:44, David Fogel wrote:
I'll try Jetty to see if it works, although I'd prefer in the long
term to use Simple. the only thing is that this is a bit more
burdensome to try for our environment, because we have an OSGi-based
stack, and I have to rebuild any new extension with a new manifest
entry to make it a bundle fragment instead of a bundle (which is how
we deploy restlet extensions, which strategy I've suggested before).
-Dave
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2465073
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2465161
Re: Content type negotiation with annotations
Hi Thierry,
Thanks, removing these lines solves the problem.
Best wishes,
Bruno.
Thierry Boileau wrote:
Hello Bruno,
thanks for the test case. You can remove the following lines from the
init method :
getVariants().add(new Variant(MediaType.TEXT_HTML));
getVariants().add(new Variant(MediaType.TEXT_PLAIN));
The getVariants list is useful when overriding the get(Variant),
post(Representation, Variant), etc. methods, not with annotated
methods which are able to describe the kind of representations they
generate.
Having said that, you can mix the getVariants approach with
annotations. For example, annotations are used for handlers of Get
requests, and the ServerResource overrides the post(Representation,
Variant) method. You can even override the getVariants method in order
to return a list of variants according to the method of the current request.
Best regards,
Thierry Boileau
Hi Thierry,
I've just tried it on 2.0-RC1.
Here is a jUnit test case.
SampleResource1 and SampleResource2 offer both plain text and HTML on
GET, and for simplicity, only HTML on POST (but that's only determined
by the method itself -- the problem is that it's not even called).
SampleResource1 uses @Post.
SampleResource2 uses @Post(html).
SampleResource3 disables content-type negotiation.
The results are that posting a x-www-form-urlencoded entity to
SampleResource1 and SampleResource2 doesn't work (the @Post-annotated
methods are not called). Sending it to SampleResource3 works (but of
course, content-type negotiation doesn't.)
It just seems that the content negotiation feature affects both request
and response types, and that the @Post annotation expect that type to be
the same both ways. Is this by design, or is it a bug?
Best wishes,
Bruno.
import org.junit.*;
import org.restlet.*;
import org.restlet.data.*;
import org.restlet.representation.*;
import org.restlet.resource.*;
import org.restlet.routing.Router;
import static org.junit.Assert.*;
public class PostAnnotationTest {
public final static String PLAINTEXT_TEST = Hello World!;
public final static String HTMLTEXT_TEST = htmlbodyh1Hello
World!/h1/body/html;
public final static String HTMLTEXT_FORM_TEST = htmlbodyh1Hello
%s!/h1/body/html;
public final static String PARAM_NAME = name;
public static abstract class AbstractSampleResource extends
ServerResource {
@Override
protected void doInit() throws ResourceException {
super.doInit();
setNegotiated(true);
getVariants().add(new Variant(MediaType.TEXT_HTML));
getVariants().add(new Variant(MediaType.TEXT_PLAIN));
}
@Get(html)
public Representation toHtml() {
return new StringRepresentation(HTMLTEXT_TEST,
MediaType.TEXT_HTML);
}
@Get(txt)
public Representation toText() {
return new StringRepresentation(PLAINTEXT_TEST,
MediaType.TEXT_PLAIN);
}
}
public static class SampleResource1 extends AbstractSampleResource {
@Post
public Representation acceptForm(Representation entity) {
if (entity
.isCompatible(new
Variant(MediaType.APPLICATION_WWW_FORM))) {
Form postForm = new Form(entity);
return new StringRepresentation(
String.format(HTMLTEXT_FORM_TEST, postForm
.getFirstValue(PARAM_NAME)),
MediaType.TEXT_HTML);
} else {
setStatus(Status.CLIENT_ERROR_BAD_REQUEST);
return null;
}
}
}
public static class SampleResource2 extends AbstractSampleResource {
@Post(html)
public Representation acceptForm(Representation entity) {
if (entity
.isCompatible(new
Variant(MediaType.APPLICATION_WWW_FORM))) {
Form postForm = new Form(entity);
return new StringRepresentation(
String.format(HTMLTEXT_FORM_TEST, postForm
.getFirstValue(PARAM_NAME)),
MediaType.TEXT_HTML);
} else {
setStatus(Status.CLIENT_ERROR_BAD_REQUEST);
return null;
}
}
}
public static class
Re: Content type negotiation with annotations
Hi Thierry,
I've just tried it on 2.0-RC1.
Here is a jUnit test case.
SampleResource1 and SampleResource2 offer both plain text and HTML on
GET, and for simplicity, only HTML on POST (but that's only determined
by the method itself -- the problem is that it's not even called).
SampleResource1 uses @Post.
SampleResource2 uses @Post(html).
SampleResource3 disables content-type negotiation.
The results are that posting a x-www-form-urlencoded entity to
SampleResource1 and SampleResource2 doesn't work (the @Post-annotated
methods are not called). Sending it to SampleResource3 works (but of
course, content-type negotiation doesn't.)
It just seems that the content negotiation feature affects both request
and response types, and that the @Post annotation expect that type to be
the same both ways. Is this by design, or is it a bug?
Best wishes,
Bruno.
import org.junit.*;
import org.restlet.*;
import org.restlet.data.*;
import org.restlet.representation.*;
import org.restlet.resource.*;
import org.restlet.routing.Router;
import static org.junit.Assert.*;
public class PostAnnotationTest {
public final static String PLAINTEXT_TEST = Hello World!;
public final static String HTMLTEXT_TEST = htmlbodyh1Hello
World!/h1/body/html;
public final static String HTMLTEXT_FORM_TEST = htmlbodyh1Hello
%s!/h1/body/html;
public final static String PARAM_NAME = name;
public static abstract class AbstractSampleResource extends
ServerResource {
@Override
protected void doInit() throws ResourceException {
super.doInit();
setNegotiated(true);
getVariants().add(new Variant(MediaType.TEXT_HTML));
getVariants().add(new Variant(MediaType.TEXT_PLAIN));
}
@Get(html)
public Representation toHtml() {
return new StringRepresentation(HTMLTEXT_TEST,
MediaType.TEXT_HTML);
}
@Get(txt)
public Representation toText() {
return new StringRepresentation(PLAINTEXT_TEST,
MediaType.TEXT_PLAIN);
}
}
public static class SampleResource1 extends AbstractSampleResource {
@Post
public Representation acceptForm(Representation entity) {
if (entity
.isCompatible(new
Variant(MediaType.APPLICATION_WWW_FORM))) {
Form postForm = new Form(entity);
return new StringRepresentation(
String.format(HTMLTEXT_FORM_TEST, postForm
.getFirstValue(PARAM_NAME)),
MediaType.TEXT_HTML);
} else {
setStatus(Status.CLIENT_ERROR_BAD_REQUEST);
return null;
}
}
}
public static class SampleResource2 extends AbstractSampleResource {
@Post(html)
public Representation acceptForm(Representation entity) {
if (entity
.isCompatible(new
Variant(MediaType.APPLICATION_WWW_FORM))) {
Form postForm = new Form(entity);
return new StringRepresentation(
String.format(HTMLTEXT_FORM_TEST, postForm
.getFirstValue(PARAM_NAME)),
MediaType.TEXT_HTML);
} else {
setStatus(Status.CLIENT_ERROR_BAD_REQUEST);
return null;
}
}
}
public static class SampleResource3 extends SampleResource2 {
@Override
protected void doInit() throws ResourceException {
super.doInit();
setNegotiated(false);
}
}
public static class SampleApplication extends Application {
@Override
public synchronized Restlet createInboundRoot() {
Router router = new Router(getContext());
router.attach(sr1, SampleResource1.class);
router.attach(sr2, SampleResource2.class);
router.attach(sr3, SampleResource3.class);
return router;
}
}
int portnumber = 5;
Component component;
@Before
public void setUp() throws
Re: A GET with query parameters?
Hi,
Any specific reason why you don't want to use a normal query like this?
http://mysite.com/farms?size=n
You could then get the query parameters with:
Form queryParams = getRequest().getResourceRef().getQueryAsForm();
String size = queryParams.getFirstValue(size);
Best wishes,
Bruno.
dj wrote:
Hi,
I'm using restlet with google app engine, but think this is just a general
restlet question.
I want to support a GET method where the user can supply some query
parameters like:
http://mysite.com/farms/size=n
so the user can do a GET on the farms list but only return a list of farms
that have a size of N. What's the proper way to do this with restlet?
I've got this:
router.attach(/farms/{size}, Farm.class);
public class Farm extends ServerResource {
@Get
public String represent() {
Request request = getRequest();
String params = getRequest().getAttributes().get(size);
}
}
that works, I'll get size=12 etc. Is this the right way to do it, or is
there some more structured approach to parameters? If I have like 12
parameters, I have to explode the string etc etc to get the param names and
their values and all that fun stuff. No big deal, just want to know if this
is the right way to go.
Thanks
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2460126
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2460147
Content type negotiation with annotations
Hi,
Firstly, I'd like to write a ServerResource that uses @Get(xml) and
@Get(html) for content negotiation on GET but not on POST (where it
would return a different content-type depending on what the method does,
or do the negotiation internally).
Secondly, I'd like to be able to post some
application/x-www-form-urlencoded content and get another type in return.
public class MyResource extends
ServerResource {
@Override
protected void doInit() throws ResourceException {
super.doInit();
setNegotiated(true);
getVariants().add(new Variant(MediaType.TEXT_HTML));
getVariants().add(new Variant(MediaType.APPLICATION_XHTML));
getVariants().add(new Variant(MediaType.APPLICATION_RDF_XML));
}
@Get(html)
public Representation toHtml() throws ResourceException {
...
}
@Get(xml)
public Representation toXml() throws ResourceException {
...
}
@Post
public Representation accept(Representation entity) throws
ResourceException {
...
}
}
At the moment, if I turn off the content-type negotiation
(setNegotiated(false)), then 'accept' is being called up receiving a
POST request. If content-negotiation is on (setNegotiated(true)), I get
a 405 (method not allowed) error.
It looks like this is due to the logic in doNegotiatedHandle(), which
I'd rather not override.
I'm not entirely sure it's because of the content-type negotiation on
the returned type, but it might be due to the input type too. (Hence the
second part of this problem.)
I've tried this @Post(html), @Post(xml) and @Post(html|xml), but
they're never called anyway, so it doesn't seem to have much to do with
the negotiated return type (the browser accepts */* by the way).
What's posted is of type application/x-www-form-urlencoded. It looks
like the @Post annotation make the negotiation on the input type too.
If I tweak client to send the same content as text/html, the
@Post(html) is called. This seems a bit wrong (posting
x-www-form-urlencoded forms and getting HTML in return seems quite
common, and that doesn't seem feasible if content-type negotiation is on).
Did I miss something? Any workarounds?
Best wishes,
Bruno.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2460162
Re: Access to HttpSession from Restlet ...
Hi, I've just submitted a patch: http://restlet.tigris.org/issues/show_bug.cgi?id=1050 It can be useful for some applications to have access to the TLS session ID. (This could possibly be used by some ongoing FOAF+SSL work for example.) Regarding the use of SSL session ID for maintaining session, this discussion should be of interest: https://issues.apache.org/bugzilla/show_bug.cgi?id=22679 Basically, nothing even guarantees that the same session ID will be used for multiple requests (it's not just about those 10-15 minutes). In addition, what RFC2818 http://tools.ietf.org/html/rfc2818 says about (TLS) sessions is: - Note that an implementation which does this MAY choose to reuse the session. [...] - It MAY resume a TLS session closed in this fashion. - Servers SHOULD be willing to resume TLS sessions closed in this fashion. - As specified in [RFC2246], any implementation which receives a connection close without first receiving a valid closure alert (a premature close) MUST NOT reuse that session. It's quoted out of context, but they're all MAYs and SHOULDs (except about invalidating the session), which implies very little in terms of what can be expected from the session ID, regarding application session management. Best wishes, Bruno. Stefan Meissner wrote: Ok Bruno, thanks for your assessement. I'll forward your expert's opinion to the architect who gave me this task :) But generally 10-15 minutes life-time of the session would be sufficient for my use-case. best regards Stefan -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2452215 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2454411
Re: M7 and TunnelService fix still not working for IE7/8 (or so it seems)
Hi, Just in case it may help, last week, I had to use the following configuration for IE8, using the snapshot in the Maven repository (org.restlet-2.0-20100210.140104-6132.jar). #Internet explorer agentName: msie acceptOld: */* acceptNew: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 agentName: msie acceptOld: image/gif, image/jpeg, image/pjpeg, application/x-ms-application, application/vnd.ms-xpsdocument, application/xaml+xml, application/x-ms-xbap, */* acceptNew: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 I'm not sure why, but for some requests, IE was sending either */* or the longer list. Best wishes, Bruno. Jerome Louvel wrote: Hi Fabian, It seems that IE6 doesn't use */* but a longer Accept HTTP header so we need to be careful. One option you have is overriding the default accept.properties file from Restlet with your own to do tests. You need to place it in a /org/restlet/service/accept.properties location, available in your classpath in front of Restlet JAR. For example, it might be possible to add several rules for IE to match all situations? Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2454011
Re: ConcurrentModificationException from Resource
Hi, The groupIds in the Maven repository have changed after 2.0M3 to take into account the notion of editions (JEE, JSE, GWT, Android). You can use org.restlet.jee or org.restlet.jse (for example) instead of org.restlet. Best wishes, Bruno. Ruben Hernando wrote: Hi, I can't see that version in maven repository (latest is 2.0M3), but next week I'll try it. Even though, yesterday we tried setting singleton=/false/ into the definition of the resource's bean in spring and it seems to work fine. I mean, it doesn't fail, but I don't know if it's the best solution. Next week I´ll feed you with 2.0M7 Regards, Rubén Hernando -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2452573
Re: Access to HttpSession from Restlet ...
Stefan Meissner wrote: What I'm still not clear about is what you're trying to do with it here (I don't how well you know SSL/TLS). Whether with Restlets or Servlets, it doesn't seem right to use that for maintaining some sort of application session. As you may have noticed I'm a newbie in all the fields you just mentioned ;) The use case I have in mind is like this: http://forums.java.net/jive/message.jspa?messageID=279268 Leaving aside the fact that on a REST-related list you won't necessarily find much advocacy for sessions... Using the SSL session ID as a session identifier for whatever your application is going to do is generally not a good idea. SSL sessions have a usually short life-time (10-15 minutes, depending on the configuration). The HTTP layer is oblivious to what's happening in terms of SSL sessions: the browser and the server will resume/invalidate them as it sees fit, more or less independently of what's going on in HTTP terms. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2452184
Re: Access to HttpSession from Restlet ...
Hi,
It currently isn't possible to retrieve the SSL session ID (in the same
way as it's possible to retrieve the cipher suite or the client
certificates from the Restlet Request.
It could make sense to implement this, and I wouldn't mind contributing
a patch to do so. Feel free to put an RFE in the issue tracker.
However, the SSL sessions have nothing to do with the Servlet's session
(and they're unlikely to be suitable as a replacement for such sessions
anyway). It would be interesting to see your particular use-case.
(As Stefan was saying, if you're using sessions to maintain state
between requests, REST and Restlet are probably not the right tool for
your project, although sometimes cookies are a necessary compromise for
storing authentication tokens, even with REST services.)
On 24/02/2010 16:10, Stefan Meissner wrote:
OK, does the same constraint apply for SSL sessions?
Is it possible to get the SSL session IDs using Simple HTTPS server connector?
Can the SSLSessionContext IDs be used in the same way as in servlet API like
this:
String sslID =
(String)request.getAttribute(javax.servlet.request.ssl_session);
What I did so far:
Server server = component.getServers().add(Protocol.HTTPS, 8183);
SeriesParameter param = server.getContext().getParameters();
param.add(keystorePath, ./mySrvKeystore);
param.add(keystorePassword, 123456);
HttpsServerHelper helper = new HttpsServerHelper(server);
SSLContext sslContext;
try {
helper.start();
sslContext = helper.getSslContext();
Enumerationbyte[] sessionIDs =
sslcontext.getServerSessionContext().getIds();
component.getDefaultHost().attach(new FilterApplication(sslContext));
// Start the component.
component.start();
} catch (Exception e) {
e.printStackTrace();
}
I also called the getIds() method inside the FilterApplication
(beforeHandle), but in most of the cases there is no session ID present upon
request. And if there is one ID it contains weird characters such as the
follwing
session ID: K?7?%?[?s?#1GGb?2???^?a??
I've tried several charsets using:
String sID = new String(id,UTF-8);
but I never get a better representation of the ID.
I'd guess what you get is an enumeration of byte arrays, not Strings. An
hexadecimal serialisation into string would probably be more
appropriate. This being said, you won't necessarily get the right ID
from this enumeration if there's more than one. Passing the SSLContext
to your resources doesn't sound like good design either (again, it
depends on what you do).
Best wishes,
Bruno.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2451688
Re: Restlet client connecting to server with self signed certificate
On 11/02/2010 23:14, Rocky V wrote: 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.) I could find one org.jjsutils.jar inside restlet/lib \restlet-1.1.7\lib\org.jsslutils_0.5 but I don't see the class you mentioned The closest is SSLContextFactory.class Am I looking at wrong place ? Where can I find this class (which jar) Good point, I should make the wiki page I mentioned above clearer. When it says this doesn't depend on jSSLutils, I forget to say it's not in the same jar. The link to this jar file is available from jSSLutils's main page: http://jsslutils.googlecode.com/files/jsslutils-extra-apachehttpclient3-0.5.jar Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2446966
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=4447dsMessageId=2446390
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 useful for lot of folks who
would in first
place like to test HTTPS and then get into nitty gritty of doing the right
thing eventually.
Well, that's true, but I don't think this should
Re: Restlet Client class with custom SSLSocket/SSLContext
Hi Adrian, In Restlet 2, you can pass SslContextFactories to the client context. import org.restlet.engine.security.SslContextFactory; import org.restlet.engine.security.DefaultSslContextFactory; ... // Example with the default SslContextFactory SslContextFactory sslContextFactory = new DefaultSslContextFactory(); sslContextFactory.setKeyStorePath(...); // ... sslContextFactory.setTrustStorePath(...); sslContextFactory.setTrustStorePassword(...); // ... // you may need client.setContext(new Context()); Context context = client.getContext(); context.getAttributes().put(sslContextFactory, sslContextFactory); You can use other implementations of SslContextFactory. - The DefaultSslContextFactory behaves according to the default values in the JSSE Ref documentation; it uses the values set in its fields (e.g. setTrustStorePath) if set, otherwise uses the values in the standard JSSE system propery (javax.net...), otherwise uses the default values for the provider. - org.restlet.ext.ssl.JsslutilsSslContextFactory (in the org.restlet.ext.ssl module) will let you wrap any jSSLutils SSLContextFactory http://www.jsslutils.org/. - org.restlet.ext.ssl.PkixSslContextFactory will let you use jSSLutils's PKIXSSLContextFactory, so you can set CRLs explicitly for example (see Javadoc). You can provide your own implementation of org.restlet.engine.security.SslContextFactory; alternatively, let me know if you'd like to work with jSSLutils (comments and suggestions welcome). If you work with Restlet 1, there are workarounds depending on the connector you want to use, but it's not ideal. Best wishes, Bruno. webp...@tigris.org wrote: Hi There, How do I make Client class in Restlet use my own custome SSLSocket/SSLContext? I already have an application that is using Restlet Client to talk to a Web Service and I've create my own X509KeyManager and X509TrustManager which I would like to use when Client sets up the SSL link to the server. Thanks for your help, Adrian -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2444683 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2444819
Re: @Get for many Variants
Hi,
You could use org.restlet.engine.converter.ConverterHelper too.
You might want to register your own Converter if you're not satisfied
with the default ones. In this case, the if-MediaType logic will be in
the ConverterHelper's toRepresentation method.
public class SearchResource extends ServerResource {
@Get(xml)
public SearchResults doXmlSearch() {
return doSearch(getRequest());
}
@Get(json)
public SearchResults doJSonSearch() {
return doSearch(getRequest());
}
}
Best wishes,
Bruno.
Thierry Boileau wrote:
Hello,
you can override the ServerResource#get(Variant) method (which is
historically the fundation of the Resource's behaviour, with the post,
put, etc methods):
@Override
protected void doInit() throws ResourceException {
// Declare the list of supported variants.
getVariants().add(new Variant(MediaType.APPLICATION_XML));
getVariants().add(new Variant(MediaType.APPLICATION_JSON));
}
@Override
protected Representation get(Variant variant) throws ResourceException {
Representation result = null;
MediaType type = variant.getMediaType();
if (MediaType.APPLICATION_XML.equals(type)) {
result =new
XmlSearchResponseRepresentation(doSearch(getRequest()));
} else if (MediaType.APPLICATION_JSON.equals(type)) {
result = new
JSonSearchResponseRepresentation(doSearch(getRequest())); }
return result;
}
Best regards,
Thierry Boileau
Hi everyone,
I'm using restlet to write a Search service..
This service will respond in XML or JSon..
Actually I have a code like that :
== 8 ==
public class SearchResource extends ServerResource {
@Get(xml)
public Representation doXmlSearch(Variant v) throw ResourceException {
return new XmlSearchResponseRepresentation(doSearch(getRequest()));
}
@Get(json)
public Representation doJSonSearch(Variant v) throw ResourceException {
return new JSonSearchResponseRepresentation(doSearch(getRequest()));
}
}
== 8 ==
As you can see, the unique difference is the Representation name. So I
wonder if it is a way to write only one method that make a if on the
requested variant to create an Xml or JSon representation..
Thanks
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2440940
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2441238
Re: including restlet in a maven project
Hello, Marc Limotte wrote: Great, this worked for me... got 2.0-m6, although I had to use the instructions to manually download it into my local repository. You can also add the repository to your POM: repositories repository idrestlet/id namePublic online Restlet repository/name urlhttp://maven.restlet.org/url /repository /repositories Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2440682
Re: how to set up client certificate in restlet 1.1.4 for HTTPS?
Hi,
Using client-certificates with Restlet 1.1 is not well supported (in
fact, it's not supported at all, but there are workarounds to make it
work in some cases). I'd suggest upgrade to Restlet 2; there might still
be bugs with some connectors, but the Apache HTTP client and the Net
connector (default java.net package classes) seem to work fine.
If you can't upgrade to Restlet 2, you could try a few things:
- Using the Net connector and the same settings.
- You might also want to try to have the keystore have the same password
as the key itself.
- I would also avoid to use the same keystore for the client and the
server. Either have one common keystore file for the truststore (to
recognise your CAs) and two separate keystore keystores (one for the
client, one for the server, with their respective private keys); or
import the CA certificates into both client and server keystores.
- You could also try the Apache HTTP client connector, using the
workaround described in this comment
http://restlet.tigris.org/issues/show_bug.cgi?id=586#desc4 (not very
clean).
Best wishes,
Bruno.
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=2430857
Re: 'java.security.UnrecoverableKeyException: Cannot recover key' in https Restlet client
Hi Mikis, This definitely sounds like a bug. I'll try to address it shortly. Meanwhile, I'd suggest working around it by using another connector if you can (for example, but putting the org.restlet.ext.net or org.restlet.ext.httpclient on the classpath if you can). I suspect that these connectors may trigger similar problems with $HOME/.keystore since we've introduced client-side certificate support (in 2.0-M6). Jerome, Thierry and the rest of the community, any thoughts about removing the default value of $HOME/.keystore when trying to load a keystore (removing it for both client and server side would be easier)? Essentially, this would mean that Restlet no longer assumes that the keystore (what contains the local certificate and private key) is in $HOME/.keystore by default, and thus users would have to specify it anyway (either via API or via the usual system property). This would be consistent with the (absence of) default value in the JSSE reference guide http://java.sun.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#Customization. I'm only talking about the _keystore_, not the _truststore_ (those default values are specified and would remain the same: either default values in line with the JSSE ref guide, values specified by the system properties, or values specified via the Restlet API -- SslContextFactories/connector parameters). Best wishes, Bruno. Mikis Seth Sørensen wrote: Hi Bruno If the keystore isn't found an java.io.FileNotFoundException, see stacktrace iC:\Users\mikis\.keystore (Den angivne fil blev ikke fundet) at java.io.FileInputStream.open(Native Method) at java.io.FileInputStream.init(FileInputStream.java:106) at java.io.FileInputStream.init(FileInputStream.java:66) at org.restlet.engine.http.StreamClientHelper.createSecureSocketFactory(StreamClientHelper.java:180) at org.restlet.engine.http.StreamClientHelper.createSocketFactory(StreamClientHelper.java:255)i In case of a invalid password a java.io.IOException is thrown: ijava.io.IOException: Keystore was tampered with, or password was incorrect at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:771) at sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:38) at java.security.KeyStore.load(KeyStore.java:1185) at org.restlet.engine.http.StreamClientHelper.createSecureSocketFactory(StreamClientHelper.java:187)i what is a bit fishy here is that a connection is actually established, even though the certificate hasn't been validated, very bold. If the certificate isn't found in the keystore a ijava.security.UnrecoverableKeyException: Cannot recover keyi is thrown. So it lookes like this is the cause for the problem. A more precise error message would have been something like 'Can not find certificate XXX in keystore ', which I'll be adding to my application. ~Mikis -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2427116
Re: 'java.security.UnrecoverableKeyException: Cannot recover key' in https Restlet client
Hello, Do you know if your user has a '.keystore' file in the home directory? Would it work better if this file was out of the way? If so, this could be related to the side effect I found when fixing http://restlet.tigris.org/issues/show_bug.cgi?id=586#desc15. I'd suggest fixing this issue by making the default keystore in Restlet connectors be unspecified, rather than assume it's going to be $HOME/.keystore: if the users want a keystore, they'll have to specify it. Best wishes, Bruno. Mikis Seth Sørensen wrote: One of the users of some software of mine, reported the following error: /java.security.UnrecoverableKeyException: Cannot recover key at sun.security.provider.KeyProtector.recover(KeyProtector.java:311) at sun.security.provider.JavaKeyStore.engineGetKey(JavaKeyStore.java:121) at sun.security.provider.JavaKeyStore$JKS.engineGetKey(JavaKeyStore.java:38) at java.security.KeyStore.getKey(KeyStore.java:763) at com.sun.net.ssl.internal.ssl.SunX509KeyManagerImpl.(SunX509KeyManagerImpl.java:113) at com.sun.net.ssl.internal.ssl.KeyManagerFactoryImpl$SunX509.engineInit(KeyManagerFactoryImpl.java:48) at javax.net.ssl.KeyManagerFactory.init(KeyManagerFactory.java:239) at org.restlet.engine.http.StreamClientHelper.createSecureSocketFactory(StreamClientHelper.java:202) at org.restlet.engine.http.StreamClientHelper.createSocketFactory(StreamClientHelper.java:255) at org.restlet.engine.http.StreamClientHelper.create(StreamClientHelper.java:153) at org.restlet.engine.http.HttpClientConverter.toSpecific(HttpClientConverter.java:505) at org.restlet.engine.http.HttpClientHelper.handle(HttpClientHelper.java:107) at org.restlet.Client.handle(Client.java:164) at org.restlet.resource.ClientResource.handle(ClientResource.java:349) at org.restlet.resource.ClientResource.put(ClientResource.java:510)/ Google tell me this is cause by the keyPassword not corresponding to the keyStore password. I can understand this could be relevant for a https server, which might have a password protected private key. But I'm acting as a https client and therefore shouldn't have any password protected keys. The code causing the error is simply: ClientResource resource = new ClientResource(context, new Reference(Protocol.HTTPS, url); resource.put; Complete code can be view at http://fisheye.agilos.org/browse/~raw,r=50111f79ea2129f8204beeefed1f69469539367a/Zendesk/src/main/java/org/agilos/jira/zendesk/NotificationDispatcher.java I'm using Restlet 1.2-M2. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2426719
Re: HTTPS with Tomcat
Hi Dustin, If you're running within Tomcat (or other servlet containers), it's Tomcat that deals with the SSL connector, not the Restlet connector. Therefore, this setup has nothing to do with what's on the Restlet wiki regarding SslContextFactories (which are only for connections with a direct connector in Restlet). You should follow the Tomcat SSL documentation for this instead. If you want to use client-certificate authentication, the Servlet connector (of Restlet) relays the certificate chain (same as with the other connectors), so you can get it from the org.restlet.https.clientCertificates attribute in the Request: this is a List of certificates (whereas javax.servlet.request.X509Certificate is an array in Servlets). Best wishes, Bruno. Dustin N. Jenkins wrote: I'm using Java 1.6, RESTlet 2.0M6, Tomcat 6.0.20, on a Linux system. My Tomcat runs a Connector on port 8443 to support HTTPS connections, and my Apache configuration is proxying to it. It's not using the AJP, but just with Redirects. I'm not sure how to setup SSL Certificates with my REST application. For the BASIC authentication with HTTP, one would use a ChallengeGuard, for example, but with HTTPS, do we still need a Guard in place to check for certificates? The setup has me confused too. See here: http://wiki.restlet.org/docs_2.0/13-restlet/28-restlet/153-restlet.html Do I need to configure a Server bean to look on the 8443 port that Tomcat already has open? I assume a SSLContextFactory of some kind needs to be configured. Has anyone got HTTPS Certificates working? Is there a guide for it? Thanks, Dustin -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2425568
Re: FirstResource Example - What is Item
Hello, I'm not sure where you got your examples from (perhaps there's a packaging error somewhere), but it's in the same package, in the subversion repository: http://restlet.tigris.org/source/browse/restlet/trunk/modules/org.restlet.example/src/org/restlet/example/firstResource/ Best wishes, Bruno. webp...@tigris.org wrote: From the FirstResource example I can't resolve 'Item'. Should this be specified from one of the imports? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2423562 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2423619
[2.0 trunk] Using get(Variant) to return representation after PUT
Hello,
I've just tried a short-cut to return the representation after a PUT:
calling get(variant), but it doesn't work as if it was doing a direct
GET. I'm not sure if it's a just a bad idea or if we should try to make
it work.
The test case looks like this:
public MyClass extends ServerResource {
@Get(xml)
public Document toXml() {
return ...;
}
public Representation put(Representation input, Variant variant) {
// Do something with input.
return get(variant);
}
}
The problem with this approach is that 'variant' is not an instance of
'VariantInfo', so in ServerResource.get(Variant), doHandle isn't called:
if (variant instanceof VariantInfo) {
result = doHandle(((VariantInfo) variant).getAnnotationInfo(),
variant);
} else {
setStatus(Status.CLIENT_ERROR_METHOD_NOT_ALLOWED);
}
To make get(variant) from a variant that's not a VariantInfo, something
like the following patch could work. I'm just not sure if it's worth
doing it this way. Any thoughts?
Best wishes,
Bruno.
diff --git
a/modules/org.restlet/src/org/restlet/resource/ServerResource.java
b/modules/org.restlet/src/org/restlet/resource/ServerResource.java
index 1dfee23..39dd86d 100644
--- a/modules/org.restlet/src/org/restlet/resource/ServerResource.java
+++ b/modules/org.restlet/src/org/restlet/resource/ServerResource.java
@@ -635,9 +635,31 @@ public abstract class ServerResource extends
UniformResource {
protected Representation get(Variant variant) throws
ResourceException {
Representation result = null;
+VariantInfo variantInfo = null;
+
if (variant instanceof VariantInfo) {
-result = doHandle(((VariantInfo) variant).getAnnotationInfo(),
-variant);
+variantInfo = (VariantInfo) variant;
+} else {
+ListVariant annoVariants = null;
+for (AnnotationInfo annotationInfo : getAnnotations()) {
+if (Method.GET.equals(annotationInfo.getRestletMethod())) {
+annoVariants = annotationInfo.getResponseVariants(null,
+getMetadataService(), getConverterService());
+if (annoVariants != null) {
+for (Variant v : annoVariants) {
+if (v.isCompatible(variant)) {
+variantInfo = new VariantInfo(variant,
+annotationInfo);
+break;
+}
+}
+}
+}
+}
+}
+
+if (variantInfo != null) {
+result = doHandle(variantInfo.getAnnotationInfo(), variant);
} else {
setStatus(Status.CLIENT_ERROR_METHOD_NOT_ALLOWED);
}
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2419000
Re: SEVERE: don't pass the component context to child Restlets anymore
Hi Jim, It's actually quite important to separate the various settings you pass to the Component (and the connectors) from those you pass to the Application itself. This way, you prevent leakage of sensitive information (such as private keys for SSL connectors) to the Application. One easy way to solve this is to set the Application's context to component.getContext().createChildContext(), either in the Application constructor or via setContext(). Best wishes, Bruno. Jim Alateras wrote: Gents, I am using the latest on 1.1 branch and am getting a whole lot of SEVERE errors. while running my test cases but they seem to be benign. SEVERE: For security reasons, don't pass the component context to child Restlets anymore. Use the Context#createChildContext() method instead.class org.restlet.Finder Oct 29, 2009 11:57:55 PM com.noelios.restlet.Engine fireContextChanged SEVERE: For security reasons, don't pass the component context to child Restlets anymore. Use the Context#createChildContext() method instead.class org.restlet.Route Oct 29, 2009 11:57:55 PM com.noelios.restlet.Engine fireContextChanged SEVERE: For security reasons, don't pass the component context to child Restlets anymore. Use the Context#createChildContext() method instead.class org.restlet.Finder Oct 29, 2009 11:57:55 PM com.noelios.restlet.Engine fireContextChanged SEVERE: For security reasons, don't pass the component context to child Restlets anymore. Use the Context#createChildContext() method instead.class org.restlet.Route Oct 29, 2009 11:57:55 PM com.noelios.restlet.Engine fireContextChanged cheers /jima -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412787 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2412844
Re: Disabling weak ciphers in Restlet
Hi, You should be able to select the cipher suites you want explicitly (otherwise, the default ones will be used) by setting the enabledCipherSuites and/or disabledCipherSuites attributes on your instance of Server. These attributes should contain a array of Strings (for example TLS_RSA_WITH_AES_128_CBC_SHA). Best wishes, Bruno. Timothy Aanerud wrote: I've been working on making my server PCI (Payment Card Industry) compliant. When my site is scanned one of the vulnerabilities reported is that my site allows the use of weak SSL ciphers. I've been looking through the documentation for jsslutils and SSLContextFactory; but I don't understand how I'm suppose to disable the 40 and 56 bit ciphers. For reference I'm running on Ubuntu 8.04 TLS, openjdk-1.6, and restlet 1.1.5, and my sslContextFactory is com.noelios.retlet.util.DefaultSslContextFactory Here is the list of weak SSL ciphers supported by the remote server : Low Strength Ciphers ( 56-bit key) SSLv3 EXP-EDH-RSA-DES-CBC-SHA Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-DES-CBC-SHA Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC4-MD5 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export TLSv1 EXP-EDH-RSA-DES-CBC-SHA Kx=DH(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-DES-CBC-SHA Kx=RSA(512) Au=RSA Enc=DES(40) Mac=SHA1 export EXP-RC4-MD5 Kx=RSA(512) Au=RSA Enc=RC4(40) Mac=MD5 export -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2408421 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2408516
Re: Integrating Apache and Restlet server like Apache and Tomcat
Hi Ashish,
As Rémi said, mod_proxy might be better for what you need. In addition,
mod_jk seems to have been deprecated in favour of mod_proxy_ajp (both
use AJP). There is more about this on the Jetty wiki:
http://docs.codehaus.org/display/JETTY/Configuring+AJP13+Using+mod_jk
The only case where I've needed mod_jk (rather than
mod_proxy/mod_proxy_ajp) was because it's the only one that can relay
the full chain of client certificates (for SSL/TLS client
authentication) obtained by Apache Httpd.
If you really want to use AJP, you have to use something like this
(based on http://www.restlet.org/documentation/1.1/firstSteps):
public static void main(String[] args) {
try {
// Create a new Component.
Component component = new Component();
// Add a new AJP server listening on port 8182.
component.getServers().add(Protocol.AJP, 8182);
// Attach the sample application.
component.getDefaultHost().attach(new FirstStepsApplication());
// Start the component.
component.start();
} catch (Exception e) {
// Something is wrong.
e.printStackTrace();
}
}
Best wishes,
Bruno.
Ashish Sharma wrote:
Bruno,
Can you post a simple code sample for reference.
As I am a newbie.
Thanks in advance!!
Ashish
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2398769
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2398809
Re: Integrating Apache and Restlet server like Apache and Tomcat
Hi Ashish, Ashish Sharma wrote: Hello, I have my Apache http server running on localhost:80 and restlet server on localhost:8182, but I want to configure above combination just like Apache http server and Apache tomcat servlet container can be configured with mod_jk library. Is it possible? Yes, it's possible. You need to use the AJP protocol (Protocol.AJP instead of Protocol.HTTP in your server configuration). This is supported by the Jetty connectors (so you'd need the corresponding jars on the classpath too). Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2398607
Re: Client Authentication PKI
Hi Dan, The idea is to pass an instance of an SslContextFactory as an attribute (or a class name as a parameter) of the Context. In the 1.1 branch on the server side, the SSLContext is set up as follows: 1. If there is a *instance* of SslContextFactory in the sslContextFactory *attribute* of the server's context, this is what's used to make the SSLContext. 2. Else, if there is the *name* of a class that implements SslContextFactory in the sslContextFactory *parameter* of the server's context, this is what is used to make the SSLContext. This is what's described on the wiki page you mentioned: parameters.add(sslContextFactory, com.noelios.restlet.ext.ssl.PkixSslContextFactory); 3. Else, it tries the various parameters given in the connector (keystorePath, keystorePassword, ...), the default values being those passed via the javax.net.ssl.* system properties. The idea with this patch (which is in the 2.x branch) is to do the same on the client side. It is only supported with the java.net connector (not the Apache HTTP client library yet). If you want to do something a bit specific with your own API, you'd need to provide your own implementation of SslContextFactory (or use one that uses the jsslutils wrapper perhaps) and pass it into the sslContextFactory attribute of the client's context (again, that only works in the 2.x branch). Alternatively, if you're using the 1.1 branch, you can use the workaround described in this comment http://restlet.tigris.org/issues/show_bug.cgi?id=586#desc4, using the Apache HTTP client connector. I must say this is not a clean way to achieve this goal. Best wishes, Bruno. Dan S wrote: I am sorry I don't fully understand your suggestion. The org.restlet.Client takes a org.restlet.Context object yet com.noelios.restlet.util.SslContextFactory does not extend org.restlet.Context. The createSslContext() method of the com.noelios.restlet.util.SslContextFactory class returns a javax.net.ssl.SSLContext object which also does not extend org.restlet.Context. Please clarify, thanks! Hi Dan, You can't really do this with a ChallengeScheme/ChallengeResponse or something similar, since it the certificates are passed at the SSL/TLS layer, which is under HTTP. If you don't want to use the system properties, you can use your own SslContextFactory passed as an argument to the client connector. Best wishes, Bruno. Dan S wrote: I noticed the example on http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet/213-restlet.html which configures one way SSL between the server and client by setting the system properties javax.net.ssl.trustStore, javax.net.ssl.trustStoreType, javax.net.ssl.trustStore.Password for the client. I have a requirement to set up two way SSL and not to use the aforementioned system properties. I am trying to piece together from the API how to do this. I realize I have to use the org.restlet.data.ChallengeResponse. I was thinking of using the constructor ChallengeResponse(ChallengeScheme scheme, String identifier, SeriesParameter parameters). I just wasn't about a few things. For the ChallengeScheme can I use ChallengeScheme.CUSTOM? What do I use for the identifier argument? For SeriesParameter argument do I just load them much the same way they are loaded on http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet/213-restlet.html (just replacing with the context for the Client and adding the trustore properties)? Is there anything else I might need? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2396050 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2396138 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2396507
Re: Client Authentication PKI
Hi Dan, You can't really do this with a ChallengeScheme/ChallengeResponse or something similar, since it the certificates are passed at the SSL/TLS layer, which is under HTTP. If you don't want to use the system properties, you can use your own SslContextFactory passed as an argument to the client connector. Best wishes, Bruno. Dan S wrote: I noticed the example on http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet/213-restlet.html which configures one way SSL between the server and client by setting the system properties javax.net.ssl.trustStore, javax.net.ssl.trustStoreType, javax.net.ssl.trustStore.Password for the client. I have a requirement to set up two way SSL and not to use the aforementioned system properties. I am trying to piece together from the API how to do this. I realize I have to use the org.restlet.data.ChallengeResponse. I was thinking of using the constructor ChallengeResponse(ChallengeScheme scheme, String identifier, SeriesParameter parameters). I just wasn't about a few things. For the ChallengeScheme can I use ChallengeScheme.CUSTOM? What do I use for the identifier argument? For SeriesParameter argument do I just load them much the same way they are loaded on http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet/213-restlet.html (just replacing with the context for the Client and adding the trustore properties)? Is there anything else I might need? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2396050 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2396122
Re: Client Authentication PKI
I should also say that this feature has only been implemented quite recently on the client side, so you might need a recent version of Restlet. More on this topic at: http://restlet.tigris.org/issues/show_bug.cgi?id=586 Best wishes, Bruno. Bruno Harbulot wrote: Hi Dan, You can't really do this with a ChallengeScheme/ChallengeResponse or something similar, since it the certificates are passed at the SSL/TLS layer, which is under HTTP. If you don't want to use the system properties, you can use your own SslContextFactory passed as an argument to the client connector. Best wishes, Bruno. Dan S wrote: I noticed the example on http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet/213-restlet.html which configures one way SSL between the server and client by setting the system properties javax.net.ssl.trustStore, javax.net.ssl.trustStoreType, javax.net.ssl.trustStore.Password for the client. I have a requirement to set up two way SSL and not to use the aforementioned system properties. I am trying to piece together from the API how to do this. I realize I have to use the org.restlet.data.ChallengeResponse. I was thinking of using the constructor ChallengeResponse(ChallengeScheme scheme, String identifier, SeriesParameter parameters). I just wasn't about a few things. For the ChallengeScheme can I use ChallengeScheme.CUSTOM? What do I use for the identifier argument? For SeriesParameter argument do I just load them much the same way they are loaded on http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet/213-restlet.html (just replacing with the context for the Client and adding the trustore properties)? Is there anything else I might need? -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2396050 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2396122 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2396125
Re: Client HTTPS Invalid keystore format
Hi Laurent, Laurent Garrigues wrote: keytool -genkey -v -alias serverX -dname CN=serverX,OU=IT,O=JPC,C=GB -keypass password -keystore serverX.jks -storepass password -keyalg RSA -sigalg MD5withRSA -keysize 2048 -validity 3650 I'd suggest using SHA1withRSA instead of MD5withRSA, since there have been known exploits against MD5. Just to clarify for the rest of your experiment, since you're testing using localhost, the DN must be something like CN=localhost, keytool -export -v -alias serverX -file serverX.cer -keystore serverX.jks -storepass password sudo keytool -delete -alias serverX -file serverX.cer -keystore /usr/lib/jvm/java-6-sun/jre/lib/security/cacerts -storepass changeit sudo keytool -import -alias serverX -file serverX.cer -keystore /usr/lib/jvm/java-6-sun/jre/lib/security/cacerts -storepass changeit ** On my server I have this line for configuring the https : *** System.setProperty(javax.net.ssl.trustStore,/usr/lib/jvm/java-6-sun/jre/lib/security/cacerts); System.setProperty(javax.net.ssl.trustStorePassword,changeit); You don't really need these lines above, since they are the default values. In addition, unless you're planning to use client-certificate authentication, you don't really need to configure the trust store on the server side. Server server = component.getServers().add(Protocol.HTTPS, 8283); SeriesParameter parameters = server.getContext().getParameters(); /* Requis pour l'HTTPS */ parameters.add(sslContextFactory,org.restlet.ext.ssl.PkixSslContextFactory); Unless you're planning to use client-certificate authentication, the DefaultSslContextFactory should be sufficient: parameters.add(sslContextFactory,org.restlet.util.DefaultSslContextFactory); (or com.noelios.restlet with Restlet 1.x). parameters.add(keystorePath, /home/laurent/Bureau/serverX.jks); parameters.add(keystorePassword, password); parameters.add(keyPassword, password); parameters.add(keystoreType, JKS); * On the client side, I suspect you might have found a bug in org.restlet.engine.http.StreamClientHelper. It seems to be expecting a keystore file in ~/.keystore by default, which you probably don't need anyway (unless using client-cert auth). If you have such a file, I'd try to move it out of the way to see if it makes a difference (although I'd expect that not finding the file would make the StreamClientHelper throw a FileNotFoundException). Alternatively, I'd use another connector than the StreamClientHelper if you can: do you have either org.restlet.ext.net or org.restlet.ext.httpclient (with their dependencies) on your classpath? Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2386072
Re: Auth by client's certificate
Hi, I'm not sure. If GrizzlyServerCall is running from the same thread the SSLReadFilter is used, SSLReadFilter.doPeerCertificateChain(...), with the selection key in the GrizzlyServerCall should work. What you need ultimately is to get hold of the SSLSession (via SSLEngine or SSLSocket), invalidate this session, re-set the want/need parameter, re-start the handshake (and make sure it has completed before proceeding). I think the biggest problem, from the Restlet point of view, is that the higher level classes (Restlet/Resource/...) would need somehow to be able to get hold of the HttpServerCall to trigger this (and supporting this feature would also depend on the connector implementation). This would be something unusual compared with the rest of the architecture of the Restlet framework. I'm not sure what the rest of the community (in particular Jerome and Thierry) would think about that. I'd be happy to assist, but I'm not sure how big the modifications in the API and Restlet architecture would be. Best wishes, Bruno. Evgeny Shepelyuk wrote: Hi Thnx for this answert I have one small request Can you point to Grizzly classes how this goal can be achieved ? Hi Evgeny, Evgeny Shepelyuk wrote: Hello, I'm using Jetty as restlet HTTP engine with SSL enabled and client's certificate auth. Probabaly it's more related to Jetty but is this possible to make server only ask for certificates only for certain URL. I'm NOT USING needClientAuthentication, so certificate is not mandatory, but what i want is following - for certain resources still use HTTPS, but never let browser to ask for client's certificate. Only way i сan see now - is creating 2 HTTPS connectors and run 2 server sockets within restlet app. In principle, this can be achieved by re-negotiating the handshake. This is something that Tomcat supports if the listening socket isn't configured to want or need authentication but CLIENT-CERT is used within the webapp. As far as I know, Jetty (as a container) doesn't support it. I don't think its API supports it either. The Grizzly library has some support for this mechanism. The Restlet API doesn't support it at the moment. Currently, the client certificate is populated when the handler is set up (when the socket is connected), after that, the upper layers (Application/Resource/...) can't talk back to the socket to tell it to re-negotiate. This is not impossible, but it would require some changes in the API, in particular HttpServerCall and the way the client certificate is then passed to the request attributes. I also reported a bug about this using Glassfish/Grizzly (nothing Restlet-specific) a few months ago; I haven't tried more recently. https://grizzly.dev.java.net/issues/show_bug.cgi?id=416 This would definitely be a problem to implement this feature in Restlet if the libraries used by the connectors don't support it. A possible workaround might be to use Restlet within Tomcat and to use CLIENT-CERT for the URI patterns (defined in web.xml) that you know will want client-certificate authentication. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2385222 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2385695
Re: Client HTTPS Invalid keystore format
Hi Laurent,
Where do you put this file and/or where do you configure it (are you
passing it via system properties)? It might not be using the file you
want. I suspect that, if you haven't configured anything more, it would
be using the cacerts file provided with your JRE.
Best wishes,
Bruno.
webp...@tigris.org wrote:
hello,
I'm using restlet 2.0 and I've issues with the HTTPS for my client
application.
I'm testing on a localhost, so my client and my server are on the same
computer.
The aim of my application is to put some information into a database.
When I launch my client application I get the following error :
java.io.IOException: Invalid keystore format
at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:633)
at
sun.security.provider.JavaKeyStore$JKS.engineLoad(JavaKeyStore.java:38)
at java.security.KeyStore.load(KeyStore.java:1185)
at
org.restlet.engine.http.StreamClientHelper.createSecureSocketFactory(StreamC
lientHelper.java:187)
at
org.restlet.engine.http.StreamClientHelper.createSocketFactory(StreamClientH
elper.java:258)
at
org.restlet.engine.http.StreamClientHelper.create(StreamClientHelper.java:15
3)
at
org.restlet.engine.http.HttpClientAdapter.toSpecific(HttpClientAdapter.java:
522)
at
org.restlet.engine.http.HttpClientHelper.handle(HttpClientHelper.java:106)
at org.restlet.Client.handle(Client.java:223)
at org.restlet.resource.ClientResource.handle(ClientResource.java:583)
at org.restlet.resource.ClientResource.handle(ClientResource.java:558)
at org.restlet.resource.ClientResource.get(ClientResource.java:392)
at client.ClientMain.main(ClientMain.java:96)
I've re-generate the jks file but the error is still there.
I've tried to use the application in a browser (after implementing a get
method) and I didn't get the error, put when I tried the get in the client,
the error is back again.
Have I missed something in the https configuration of my client?
Please find below the details of my client application:
public class ClientMain {
@SuppressWarnings(unchecked)
public static void main(String[] args) throws IOException,
ResourceException {
ClientResource itemsResource = new ClientResource(
https://localhost:8283/items;);
itemsResource.setChallengeResponse(ChallengeScheme.HTTP_BASIC,
root, root);
/*partie facture*/
JSONObject json = new JSONObject();
json.put(Client_id, 80);
json.put(Denomination, rien du tout);
/*Partie sous facture*/
String[][] lignes_factures = new String[1][4];
lignes_factures[0][0] = Facture 1;
lignes_factures[0][1] = Achat de croquettes;
lignes_factures[0][2] = 60;
lignes_factures[0][3] = 600;
json.put(lignes_associées, lignes_factures);
/*Representation r = */ itemsResource.post(getRepresentation(json));
}
@SuppressWarnings(unchecked)
public static Representation getRepresentation(JSONObject json) {
Representation rep = new JsonRepresentation(json);
return rep;
}
}
Thanks by advance for your help.
Kind regards,
Laurent Garrigues
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2385623
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2385709
Re: Auth by client's certificate
Hi Evgeny, Evgeny Shepelyuk wrote: Hello, I'm using Jetty as restlet HTTP engine with SSL enabled and client's certificate auth. Probabaly it's more related to Jetty but is this possible to make server only ask for certificates only for certain URL. I'm NOT USING needClientAuthentication, so certificate is not mandatory, but what i want is following - for certain resources still use HTTPS, but never let browser to ask for client's certificate. Only way i сan see now - is creating 2 HTTPS connectors and run 2 server sockets within restlet app. In principle, this can be achieved by re-negotiating the handshake. This is something that Tomcat supports if the listening socket isn't configured to want or need authentication but CLIENT-CERT is used within the webapp. As far as I know, Jetty (as a container) doesn't support it. I don't think its API supports it either. The Grizzly library has some support for this mechanism. The Restlet API doesn't support it at the moment. Currently, the client certificate is populated when the handler is set up (when the socket is connected), after that, the upper layers (Application/Resource/...) can't talk back to the socket to tell it to re-negotiate. This is not impossible, but it would require some changes in the API, in particular HttpServerCall and the way the client certificate is then passed to the request attributes. I also reported a bug about this using Glassfish/Grizzly (nothing Restlet-specific) a few months ago; I haven't tried more recently. https://grizzly.dev.java.net/issues/show_bug.cgi?id=416 This would definitely be a problem to implement this feature in Restlet if the libraries used by the connectors don't support it. A possible workaround might be to use Restlet within Tomcat and to use CLIENT-CERT for the URI patterns (defined in web.xml) that you know will want client-certificate authentication. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2385222
Re: Patch for MetadataService to support XSL files with the more common extension .xsl
Hi Fabian, The procedure to contribute to Restlet is described here: http://www.restlet.org/community/contribute In short, for a patch to be included, you would have to sign the JCA and get in touch with Jerome or Thierry. Best wishes, Bruno. Fabian Mandelbaum wrote: Hello, I've asked on this busy ML about the procedure to submit a (small) patch to MetadataService and got no answer so far. I suppose everyone is as busy as I am. So, I'm taking the liberty to post this message with the (small) patch attached. This patch was generated on MetadataService.java from Restlet 2.0M4's JEE distribution, with diff -u. It adds out-of-the-box support for XSL files using the (more common than .xslt) .xsl extension. Please, consider including this small contribution into the next iteration of Restlet 2.0, thank you! -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2383638
Re: Restlet SSL and Weblogic (even tomcat would help)
Hi Andy, webp...@tigris.org wrote: When I started this as a Java application, I didn't need any other relavent configuration, no web.xml. I don't really understand how but somehow this starts up a Jetty Container. I am told (please correct if I am wrong) that somewhere in org.restlet.Component or org.restlet.Application code there is black box code that fires off a Jetty container. We do no special container based configuration for this. As best as I understand it, to run this deployed as a web application in another container, I need the web.xml, and need to set the conext-param parameter org.restlet.application to my implementation/extension of an org.restlet.Application as described towards the top of this Javadoc: http://www.restlet.org/documentation/1.0/ext/com/noelios/restlet/ext/servlet/ServerServlet.html. This will not involved the ServicesCompont extension of the component class that I have in the peice of code above. We actually got the ServicesApplication deployed this way to tomcat using Form authentication (with out the SSL code obviously). Trying to deploy my applicaton to Weblogic is what I was trying to do with the web.xml. Bruno, I'm going to try some things based on your input and will let the thread know how it works out, or post more targeted questions if I need to. If you can add anything based on my clarification here, it would be greatly appreciated. In the stand-alone mode (the way you got it to work, without web.xml), you're starting a Restlet Component that will use the first appropriate connector it finds on the classpath for the relevant protocol [1]. For example, if you put the com.noelios.restlet.ext.jetty.jar file onto the classpath, the Jetty connectors will be used. This is not actually running a Jetty 'container', but only using the HTTP server part of Jetty (that is, the part you can embed in other Java apps, without it being a complete Servlet container). In this case, the socket (and its SSL configuration) is ultimately handled by the Jetty API, via the Restlet configuration layer (which is the way you've done it). If you want to run your application within a Servlet container, you need use the Servlet connector, and thus you need to put com.noelios.restlet.ext.servlet.jar instead of com.noelios.restlet.ext.jetty.jar on your classpath. You also need to package your application in a War format (or equivalent) and to configure everything in the web.xml file. In this mode, the sockets are not directly accessible by the Restlet component, and the SSL configuration needs to be done at the Servlet container level (via the Connector/ in server.xml in Tomcat, for example), and possibly in web.xml (if you want re-negotiation, but it's probably simpler not to configure any CLIENT-CERT auth in web.xml to start with, and to use want or need in the Connector/ configuration instead). Best wishes, Bruno. [1] http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/37-restlet.html -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2372646
Re: Restlet SSL and Weblogic (even tomcat would help)
Hello, Andrew Whelan wrote: Hello, I am trying to deploy a Restlet application as a Servlet to weblogic using SSL for authentication and authorization. I have successfully gotten the SSL authentication to work with my Restlet, running it as a Java application using the default Jetty container. Now I'm trying to deploy it to weblogic. I am trying to use mutual authentication. I have client and server keystores and a trustore for each. I used OpenSSL to create a certificate authority and have signed client and server certificates correctly imported into their respective truststores. I have the SSL code used for the class that extends org.restlet.Application. That class gets associated with the necessary org.restlet.application context-param in the web.xml when trying to configure the servlet(see it below the code). Besides A)The code in the class below that extends Application B)The content of the web.xml that follows the class C)Adding a user with a username that matches that of the distinguished name of the client certificate Should I have to do anything else? [...] security-constraint web-resource-collection web-resource-nameData Services/web-resource-name url-pattern/*/url-pattern http-methodGET/http-method http-methodPOST/http-method http-methodPUT/http-method /web-resource-collection auth-constraint role-nameuser/role-name /auth-constraint login-config auth-methodCLIENT-CERT/auth-method /login-config security-role role-name user /role-name /security-role /security-constraint /web-app In Tomcat, with a traditional Servlet, when the connector isn't configured to ask for a client certificate (not sure if you have done so), the settings you're using would trigger a re-negotiation (a new SSL/TLS handshake which will ask for a certificate). As far as I know, this feature isn't supported in Jetty (in-built or as a full container). I would have expected com.noelios.restlet.ext.servlet.ServerServlet not to behave differently from other Servlets in that respect (even if it would ignore the container's roles). In the configurations I got to work using this approach (with JSP or other servlets), the login-config and security-role elements are outside (just after) the security-constraint element, and also use user-data-constraint: web-app display-nameMy Webapp/display-name ... security-constraint web-resource-collection web-resource-nameApp/web-resource-name url-pattern//url-pattern /web-resource-collection auth-constraint role-namecert/role-name /auth-constraint user-data-constraint transport-guaranteeCONFIDENTIAL/transport-guarantee /user-data-constraint /security-constraint login-config auth-methodCLIENT-CERT/auth-method /login-config security-role role-namecert/role-name /security-role /web-app Another solution is to configure the connector (rather than the webapp) to ask for the client certificate. In this case, there is no re-negotiation, since the client certificate is requested during the first handshake when the client makes the connection. I'm not sure how this is done in Weblogic, but in Tomcat, it's in server.xml: Connector port=8443 protocol=HTTP/1.1 SSLEnabled=true maxThreads=150 scheme=https secure=true keystore=... keystoreType=PKCS12 keystorePass=... truststoreFile=... truststoreType=JKS truststorePass=... clientAuth=want sslProtocol=TLS / You get three choices for 'clientAuth': - false: no client auth, - want: requests a client certificate, but it's optional, - need: requires a client certificate; if the client doesn't give one, the connection will be closed at the SSL/TLS level, without giving the server the opportunity to send an error page. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2372018
Re: Question about 'org.restlet.engine.Engine.registerHelper(ClassLoader, URL, List, Class)'
Hi, Marcelo Paternostro wrote: My environment is: - Eclipse 3.5 - The Jetty support offered by Eclipse So I've added all 'org.mortbay.jetty.*' bundles that come with Eclipse plus 'org.restlet.ext.jetty' to the class path and run the basic restlet example just to see it dying in a NoClassDefFoundError agony. After a lot of digging, I understood the problem: 'org.restlet.ext.jetty.jar!/META-INF/services/org.restlet.engine.ServerHelper' declares 3 helpers (AJP, HTTP, HTTPS) and Eclipse has support for only one of them (HTTP). So when the method in the subject tries to load the other helper classes (for AJP and HTTPS), everything breaks down due to the fact that their dependencies are not in the class path. I manage to hack a workaround by overriding the referred method to ensure that only the HTTP helper is registered. Everything seems to be working fine now. I have 2 question though: 1. Can anyone foresee a problem on my approach (other than not having AJP and HTTPS)? The Jetty extension in Restlet (org.restlet.ext.jetty.jar) provides AJP, HTTP and HTTPS connectors indeed, but they're effectively using Jetty directly within a stand-alone Restlet application, rather than Restlet within a Jetty container. If you want to use Restlet within the Jetty container offered by Eclipse, you should the Servlet extension instead: this can run Restlet applications and components within an Servlet environment. It is documented here: - http://www.restlet.org/documentation/1.1/faq#02 - http://www.restlet.org/documentation/1.1/ext/com/noelios/restlet/ext/servlet/ServerServlet.html Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2372055
Re: Licensing question
Hello, (Please don't consider what I'm saying here as legal advice...) Restlet 1.1.4 only bundles the compiled code (so no source code to scan there) and provides a link to https://sjsxp.dev.java.net/. The source bundle I've been able to get from https://sjsxp.dev.java.net/ (I'm not sure it's the exact same version) contains a file called 'LICENCE.html' which is a dual licence: CDDL 1.0 and GPL 2.0. The only reference to BEA I've found is in the header of each source file, in the @author tag: Copyright (c) 2003 by BEA Systems. All Rights Reserved. As far as I'm aware, this is just a copyright statement, not a BEA licence. There doesn't seem to be any licence in the file themselves, therefore, the licence is that written in the 'LICENCE.html' file in the bundle (provided that BEA indeed granted that licence in the first place, of course). Best wishes, Bruno. Jennifer Carlucci wrote: As part of clearing Restlet v1.4 through our legal team to include it in our product, we did code scans of the javax.xml.stream package. The license.txt shows that the bundle is licensed under CDDL, but the code scans show that the source contains the BEA license. Does the CDDL license that's found in the bundle override the BEA license that's found in the source? Thanks, Jennifer Carlucci -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2371310
Re: Content Negotiation for Safari 4. Any way to override?
Hi Bruce/Thierry, It seems that the code has changed between version 1.1 and 2.0. In 1.1.5, com.noelios.restlet.application.TunnelFilter uses 'equalsIgnoreCase' (line 388), whereas in the trunk (2.0), org.restlet.engine.application.TunnelFilter uses 'equals' (line 528). I think it makes sense to use 'equals' instead of 'equalsIgnoreCase' (although I'm not sure which one is best), but the accept.properties files should probably be updated to reflect this change (the version in the trunk still uses lower case for all agent names). Best wishes, Bruno. Bruce Cooper wrote: Hi guys, I have found that the agentName is reporting as Safari with a capitol S whereas the standard file has it listed with a lowercase s, so I've needed to add a separate rule in accept.properties. Because I want to only override the default Accept that is being sent through (and so that I can put in other accepts in XMLHttpRequest requests and not have them overridden)//, I think it is best to include the acceptOld as shown below:// #Safari agentName: Safari acceptOld: application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5 acceptNew: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 This appears to work for me, so I'm happy. Let me know if you think it is a good solution. Bruce. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2365378
Re: Content Negotiation for Safari 4. Any way to override?
Hi Thierry,
I'm not entirely sure what the intended behaviour of the TunnelService
(regarding user-agents) is. Could you confirm this should be as follow
(assuming the user agent tunnel is switched on in the service)?
Step 1. The TunnelService parses the 'User-Agent' header and compares it
to org/restlet/data/agent.properties, therefore populating agent
attributes in the client info class.
For example (with Safari 4):
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us)
AppleWebKit/530.18 (KHTML, like Gecko) Version/4.0.1 Safari/530.18
-
{agentOsShortName=Macintosh, osData= en-us, agentName=Safari,
mozillaVersion=5.0, appleWebKitComment=KHTML, like Gecko,
familyVersion=4.0.1, agentVersion=530.18, agentOs=Intel Mac OS X 10_5_7,
appleWebKitVersion=530.18}
Step 2. The service then looks into
org/restlet/service/accept.properties, if the 'agentName' (in a given
block in this file) matches the 'agentName' in the agent attributes and
if the 'acceptOld' line (in the same block) matches the original
'Accept' header in the request, then 'Accept' is replaced with the value
in 'acceptNew'.
In the test above, the agentName is detected properly, but it seems the
blank line in the acceptOld config file doesn't mean it's a wildcard, so
there should probably be the actual Accept header sent by Safari in this
configuration file. This may be the reason why it doesn't work (it seems
to work when that line is configured to match the Accept header sent).
Best wishes,
Bruno.
P.S.: Below are a few User-Agent and Accept headers I've been able to
gather.
- Firefox 2 on XP:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-GB; rv:1.8.1.20)
Gecko/20081217 Firefox/2.0.0.20 (.NET CLR 3.5.30729)
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
(I was surprised to see that this one doesn't seem to be recognised as
'agentName=Firefox' but 'Mozilla'; here are the attributes:
{agentName=Mozilla, osData=Windows NT 5.1; en-GB; rv:1.8.1.20)
Gecko/20081217 Firefox/2.0.0.20 (.NET CLR 3.5.30729, agentVersion=5.0,
agentOs=Windows}.)
- Browser in the GWT Eclipse plugin:
User-Agent: Mozilla/5.0 (X11; U; Linux i686 (x86_64); en-US; rv:1.7.12)
Gecko/20050920
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
- iPod Touch (FW 2.2.1, not the latest):
User-Agent: Mozilla/5.0 (iPod; U; CPU iPhone OS 2_2_1 like Mac OS X;
en-us) AppleWebKit/525.18.1 (KHTML, like Gecko) Version/3.1.1
Mobile/5H11 Safari/525.20
Accept:
text/xml,application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
- MSIE 8 on XP:
Accept: */*
User-Agent: Mozilla/4.0 (compatible; MSIE 8.0; Windows NT 5.1;
Trident/4.0; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1; .NET CLR
3.0.4506.2152; .NET CLR 3.5.30729)
- Safari 4 on XP:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US)
AppleWebKit/530.17 (KHTML, like Gecko) Version/4.0 Safari/530.17
Accept:
application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
- Safari 4 on OSX:
User-Agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10_5_7; en-us)
AppleWebKit/530.18 (KHTML, like Gecko) Version/4.0.1 Safari/530.18
Accept:
application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
Thierry Boileau wrote:
Hi Bruce,
can you send us the content of the user-agent header? We will complete
the default agent.properties file.
best regards,
Thierry Boileau
Hi guys,
I'm setting up a restlet app at the moment, and I'd like to set it up so
that if a user uses a browser to access a resource, he gets given a nicely
formatted HTML page, but if he separately asks for XML or JSON he gets a
machine parsable response. Its all working well on Firefox, but I'm having
some issues getting it working on Safari 4.
It looks like the problem is the Accept: header that is being sent in by
Safari. Its
application/xml,application/xhtml+xml,text/html;q=0.9,text/plain;q=0.8,image/png,*/*;q=0.5
This causes the content negotiation process to favor xml as an output over
html, as html has a priority of 0.9. I tried xhtml, which has the same
priority as xml, but it looks like it still chooses xml (presumably it is
random which response you get if they have the same priority).
Is there a way I can override Safari's preferences? I know that it is
asking to have xml as the highest priority, but frankly I think that is
wrong.
Any suggestions that you can give would be appreciated.
Bruce.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2365031
Re: 2.0m3 and content negotiation
Hi Jerome,
Is there a full list of the annotation parameters?
According to these pages, they're not media-types:
- http://wiki.restlet.org/developers/172-restlet/226-restlet.html
-
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596334
I'm using revision 5060.
* Case 1:
public class MyResource extends ServerResource {
@Override
public void doInit() throws ResourceException {
...
setNegotiated(true);
}
@Get(xml)
public Representation toXml() {
...
}
}
Using a client with application/xml, text/xml, I get this:
GET /1/ HTTP/1.1
Host: localhost:8182
User-Agent: Noelios-Restlet/2.0snapshot
Accept: application/xml, text/xml
Connection: close
HTTP/1.1 406
...
* Case 2, same with @Get(text/xml) or @Get(application/xml), I get this:
GET /1/ HTTP/1.1
Host: localhost:8182
User-Agent: Noelios-Restlet/2.0snapshot
Accept: application/xml, text/xml
Connection: close
HTTP/1.1 200 The request has succeeded
Content-Type: application/xml
...
* Case 3, with two @Get methods:
public class MyResource extends ServerResource {
@Override
public void doInit() throws ResourceException {
...
setNegotiated(true);
}
@Get(application/xml)
public Representation toXml() {
...
}
@Get(text/plain)
public Representation toPlainText() {
...
}
}
For a plain/text request, I get this:
GET /1/ HTTP/1.1
Host: localhost:8182
User-Agent: Noelios-Restlet/2.0snapshot
Accept: text/plain
Connection: close
HTTP/1.1 200 The request has succeeded
Content-Type: application/xml
Date: Fri, 12 Jun 2009 10:55:18 GMT
Accept-Ranges: bytes
Server: Noelios-Restlet/2.0snapshot
Connection: close
Transfer-Encoding: chunked
d3
?xml version=1.0 encoding=UTF-8?
...
* Case 4, same as case 3, but swapping the order of toXml and
toPlainText in the class:
GET /1/ HTTP/1.1
Host: localhost:8182
User-Agent: Noelios-Restlet/2.0snapshot
Accept: text/plain
Connection: close
HTTP/1.1 200 The request has succeeded
Content-Type: text/plain; charset=ISO-8859-1
...
I'm not sure I understand the values of the @Get/@Put annotation
parameters. I thought they weren't media-types, but cases 1 and 2 seem
to suggest otherwise. If they're meant to be media-types, cases 3 and 4
suggest content-type negotiation doesn't work.
Could you clarify how it's meant to work?
Best wishes,
Bruno.
Jerome Louvel wrote:
Hi Fabian,
This one has just been fixed in SVN trunk but there more issues pending.
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 : Fabian Mandelbaum [mailto:fmandelb...@gmail.com]
Envoyé : jeudi 11 juin 2009 17:05
À : discuss@restlet.tigris.org
Objet : 2.0m3 and content negotiation
Hello,
what's the status of the content negotiation bug in 2.0m3? is this
fixed in current snapshot?
I'm still getting application/octet-stream for all media types other
than xml with code like this:
@Get
public Representation represent() throws ResourceException {
// Build and return representation here
}
Thanks
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2361570
Re: 2.0m3 and content negotiation
Hello,
I've just had a look in the code. I'm using @Get(txt) on toPlainText()
and @Get(xml) on toXml().
In ServerResource.getAvailableVariants(Method), when it goes through:
annoVariants = cs.getVariants(annotationInfo
.getJavaReturnType(), new Variant(
(MediaType) metadata));
the values are:
- annotationInfo.getJavaReturnType() - Representation
- metadata - MediaType.PLAIN_TEXT
Then, in ConverterService.getVariants,
helperVariants = ch.getVariants(sourceClass);
helperVariants is a list that contains only the octet-stream media type.
What I guess from this is that the Representation type is considered to
be able to be converted only to an octet-stream and the text/plain media
type is never going to be considered in the rest of
ServerResource.getAvailableVariants.
This seems a bit surprising.
ServerResource.java doesn't seem to be formatted properly in revision
5060, by the way.
Best wishes,
Bruno.
Bruno Harbulot wrote:
Hi Jerome,
Is there a full list of the annotation parameters?
According to these pages, they're not media-types:
- http://wiki.restlet.org/developers/172-restlet/226-restlet.html
-
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596334
I'm using revision 5060.
* Case 1:
public class MyResource extends ServerResource {
@Override
public void doInit() throws ResourceException {
...
setNegotiated(true);
}
@Get(xml)
public Representation toXml() {
...
}
}
Using a client with application/xml, text/xml, I get this:
GET /1/ HTTP/1.1
Host: localhost:8182
User-Agent: Noelios-Restlet/2.0snapshot
Accept: application/xml, text/xml
Connection: close
HTTP/1.1 406
...
* Case 2, same with @Get(text/xml) or @Get(application/xml), I get this:
GET /1/ HTTP/1.1
Host: localhost:8182
User-Agent: Noelios-Restlet/2.0snapshot
Accept: application/xml, text/xml
Connection: close
HTTP/1.1 200 The request has succeeded
Content-Type: application/xml
...
* Case 3, with two @Get methods:
public class MyResource extends ServerResource {
@Override
public void doInit() throws ResourceException {
...
setNegotiated(true);
}
@Get(application/xml)
public Representation toXml() {
...
}
@Get(text/plain)
public Representation toPlainText() {
...
}
}
For a plain/text request, I get this:
GET /1/ HTTP/1.1
Host: localhost:8182
User-Agent: Noelios-Restlet/2.0snapshot
Accept: text/plain
Connection: close
HTTP/1.1 200 The request has succeeded
Content-Type: application/xml
Date: Fri, 12 Jun 2009 10:55:18 GMT
Accept-Ranges: bytes
Server: Noelios-Restlet/2.0snapshot
Connection: close
Transfer-Encoding: chunked
d3
?xml version=1.0 encoding=UTF-8?
...
* Case 4, same as case 3, but swapping the order of toXml and
toPlainText in the class:
GET /1/ HTTP/1.1
Host: localhost:8182
User-Agent: Noelios-Restlet/2.0snapshot
Accept: text/plain
Connection: close
HTTP/1.1 200 The request has succeeded
Content-Type: text/plain; charset=ISO-8859-1
...
I'm not sure I understand the values of the @Get/@Put annotation
parameters. I thought they weren't media-types, but cases 1 and 2 seem
to suggest otherwise. If they're meant to be media-types, cases 3 and 4
suggest content-type negotiation doesn't work.
Could you clarify how it's meant to work?
Best wishes,
Bruno.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2361588
Re: 2.0m3 and content negotiation
Hello,
I think the problem comes from the fact that
'ConverterService.getVariants(Class? sourceClass, Variant
targetVariant)' doesn't make any use of 'targetVariant'.
As a quick workaround, I'd suggest this patch:
diff --git
a/modules/org.restlet/src/org/restlet/service/ConverterService.java
b/modules/org.restlet/src/org/restlet/service/ConverterService.java
index 73e6d83..123facd 100644
--- a/modules/org.restlet/src/org/restlet/service/ConverterService.java
+++ b/modules/org.restlet/src/org/restlet/service/ConverterService.java
@@ -110,7 +110,8 @@ public class ConverterService extends Service {
* @return The list of variants that can be converted.
*/
public ListVariant getVariants(Class? sourceClass, Variant
targetVariant) {
-ListVariant result = null;
+ListVariant result = new ArrayListVariant();
+result.add(targetVariant);
ListVariant helperVariants = null;
for (ConverterHelper ch : Engine.getInstance()
More fundamentally, with the base 'Representation' type,
ch.getVariants(Representation.class) only seems to return one variant:
application/octet-stream, whereas in fact, Representation should in
theory be usable for any content-type.
The aim of ConverterService.getVariants should probably be to find the
largest intersection between the targetVariant and the variants matching
the sourceClass ('Representation' would be usable for all variants).
However, I wonder if this is really useful, since there's always going
to be the problem when building the returned representation within the
method (for example, it doesn't prevent from making mistakes and having
a method with @Get(xml) returning a StringRepresentation built with
MediaType.IMAGE_JPEG).
Best wishes,
Bruno.
Bruno Harbulot wrote:
Hello,
I've just had a look in the code. I'm using @Get(txt) on toPlainText()
and @Get(xml) on toXml().
In ServerResource.getAvailableVariants(Method), when it goes through:
annoVariants = cs.getVariants(annotationInfo
.getJavaReturnType(), new Variant(
(MediaType) metadata));
the values are:
- annotationInfo.getJavaReturnType() - Representation
- metadata - MediaType.PLAIN_TEXT
Then, in ConverterService.getVariants,
helperVariants = ch.getVariants(sourceClass);
helperVariants is a list that contains only the octet-stream media type.
What I guess from this is that the Representation type is considered to
be able to be converted only to an octet-stream and the text/plain media
type is never going to be considered in the rest of
ServerResource.getAvailableVariants.
This seems a bit surprising.
ServerResource.java doesn't seem to be formatted properly in revision
5060, by the way.
Best wishes,
Bruno.
Bruno Harbulot wrote:
Hi Jerome,
Is there a full list of the annotation parameters?
According to these pages, they're not media-types:
- http://wiki.restlet.org/developers/172-restlet/226-restlet.html
-
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1596334
I'm using revision 5060.
* Case 1:
public class MyResource extends ServerResource {
@Override
public void doInit() throws ResourceException {
...
setNegotiated(true);
}
@Get(xml)
public Representation toXml() {
...
}
}
Using a client with application/xml, text/xml, I get this:
GET /1/ HTTP/1.1
Host: localhost:8182
User-Agent: Noelios-Restlet/2.0snapshot
Accept: application/xml, text/xml
Connection: close
HTTP/1.1 406
...
* Case 2, same with @Get(text/xml) or @Get(application/xml), I get this:
GET /1/ HTTP/1.1
Host: localhost:8182
User-Agent: Noelios-Restlet/2.0snapshot
Accept: application/xml, text/xml
Connection: close
HTTP/1.1 200 The request has succeeded
Content-Type: application/xml
...
* Case 3, with two @Get methods:
public class MyResource extends ServerResource {
@Override
public void doInit() throws ResourceException {
...
setNegotiated(true);
}
@Get(application/xml)
public Representation toXml() {
...
}
@Get(text/plain)
public Representation toPlainText() {
...
}
}
For a plain/text request, I get this:
GET /1/ HTTP/1.1
Host: localhost:8182
User-Agent: Noelios-Restlet/2.0snapshot
Accept: text/plain
Connection: close
HTTP/1.1 200 The request has succeeded
Content-Type: application/xml
Date: Fri, 12 Jun 2009 10:55:18 GMT
Accept-Ranges: bytes
Server: Noelios-Restlet/2.0snapshot
Connection: close
Transfer-Encoding: chunked
d3
?xml version=1.0 encoding=UTF-8?
...
* Case 4, same as case 3, but swapping the order of toXml and
toPlainText in the class:
GET /1/ HTTP/1.1
Host: localhost:8182
User-Agent: Noelios-Restlet/2.0snapshot
Accept: text/plain
Connection: close
HTTP/1.1 200 The request has succeeded
Content-Type: text/plain; charset
Re: Restlet with a large dataset
Hi Jean-Christophe,
You should be able to keep the memory usage small if you write to the
OutputStream directly, using an OutputRepresentation:
return new OutputRepresentation(MediaType.APPLICATION_XML) {
@Override
public void write(OutputStream out) throws IOException {
/* ... */
}
};
I'd avoid DomRepresentation for a large set, simply because of the
memory usage of the DOM model. Instead, writing the XML fragments by
hand as you iterate through the ResultSet would probably work better in
this case.
Best wishes,
Bruno.
Jean-Christophe Malapert wrote:
Hello,
I have a large dataset (a few millions of rows). I am very interesting for
the use of restlet framework on my large dataset.
Is it possible to transfer a large response by streaming without having
memory problems on the server side ? That means, in my case, to be able to
make streaming from the ResulSet coming from the database to the output by
using the JSON or XML representation.
Thanks a lot,
J-Christophe
--
Jean-Christophe Malapert
CNES/DCT/PS/TVI
18, Av. Edouard Belin
31400 Toulouse Cedex 9
France
Tel : (+33/0)5 61 28 14 45
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2361314
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2361350
Dispatching calls to resources internally
Hello,
I'm trying to perform operations on a resource in a way that affects
other resources in the same system (because they depend partly on the
same domain objects).
For example, in the tutorial
http://www.restlet.org/documentation/1.1/tutorial#part12, UserResource
and OrderResource both depend on the User domain object.
I'd like, in the messages I sent to the resources to be able to refer to
other resources, using a URI (usually relative, but perhaps absolute).
For example, if the structure of the URI is flat:
/user/{USER_ID}- UserResource - User (table where USER_ID is
the primary key)
/order/{ORDER_ID} - OrderResource - User (table where ORDER_ID is
the primary key, USER_ID being another column)
and if the default representation for an OrderResource looks like this:
order
user/user/123/user
...
/order
I'd like to be able to change the user on that order by giving another
URI, say:
order
user../user/456/user
...
/order
or with the equivalent absolute URI:
order
userhttp://host.example/user/456/user
...
/order
The way the example in the tutorial works around this is by having the
orders depend on the user in the template
(/user/{USER_ID}/order/{ORDER_ID}), so that the OrderResource can know
both the USER_ID and the ORDER_ID.
Since I'm using a flat URI structure, I can't really do this. (What
I'm trying to do is to have some parent/child relationship between
resources, without constraints on the depth of the tree, in such a way
that telling a resource X its parent is Y would also set the domain
object of Y to be a child of X, and vice-versa. I'm also assuming that
both within the scope the same system to avoid distributed updates.)
One way to do this would be to make another Request to the enclosing
Application, via 'handle'. However, going through the external interface
(GET/PUT/POST/DELETE/...) when it's an internal operation (in
particular, because I'd like to bypass the Guards/Filters and because I
want to avoid infinite loops). I'd be looking for a way to get the
instance of the Resource that would be at the given URI (so that I can
get its domain object) without the call to be actually made.
Is there a way to do this? Has anyone had similar problems and other
solutions?
Best wishes,
Bruno.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2112197
Re: Restlet 1.2 to become Restlet 2.0
Hi, This sounds sensible. Just a quick question: what does this mean with respect to support for Java 6? I thought it had been mentioned that Java 6 support was planned for Restlet 2.0. I'm not personally requiring Java 6, although support for SPNEGO would (unless we re-implement what was added to JGSS in Java 6 in Restlet, but I doubt it's worth the effort). Best wishes, Bruno. Jerome Louvel wrote: Hi all, Looking at the amount of new features that we added so far since Restlet 1.1 (with some more coming), the amount of refactoring and reorganization done in the Restlet API (touching the core Resource API) and extension packages and the growing number of special Restlet editions (Java SE/Java EE, GWT, Google App Engine and soon Android), it seems appropriate to rename the Restlet 1.2 release into Restlet 2.0. The idea is to give existing users an accurate feeling of the amount of effort required when upgrading from Restlet 1.0 or Restlet 1.1 and for new users to realize the amount of effort and changes done since Restlet 1.x. I hope it will make sense to you guys. We have updated our issue tracker and our roadmap here: http://www.restlet.org/about/roadmap Next release will be Restlet 2.0 M3 and will replace the current Restlet 1.2 M2 (tagged “testing”). 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/ -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2080653
Re: HttpClient Alternatives
Hi Rob, Rob Heittman wrote: Hi all... I think today I lost my last fight with HttpClient misbehavior... Failure to consume entity (not in my control) consumes a connection; subsequent attempts block ... This is a crummy failure mode. I'm weary. I'd like a Restlet client connector that provides the performance benefit of simple http/1.1 persistent connections, but is more aligned with Restlet API, and maybe even could support a Restlet/GWT style async callback. Anybody got the URL of a good alternative library to integrate ... Or should I just start with the Net client connector and go my own way? Here are a few pointers that may be of interest: Apache HttpClient 4.x support in Restlet: http://restlet.tigris.org/issues/show_bug.cgi?id=639 Jetty Client: http://docs.codehaus.org/display/JETTY/Jetty+HTTP+Client Plans for a Grizzly Http Client: https://grizzly.dev.java.net/servlets/ReadMsg?list=devmsgNo=2531 Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2080753
Re: Restlet 1.1.4 + Jetty + SSL - trustAnchors exception
Hello, It looks like it's the same problem as here: http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1068636. It's time for me to make a new release of jSSLutils with the fix. Meanwhile, can you use com.noelios.restlet.util.DefaultSslConte xtFactory instead? It should also use the PKIX TrustManagerFactory. (The reason I didn't notice this in the tests I ran was that I always specify a trust store and thus don't use the default ones.) Best wishes, Bruno. John Wismar wrote: On to my next issue! I'm using Restlet 1.1.4 with Jetty, and am trying to enable HTTPS. I've read the Configuring HTTPS tutorial, and the Jetty How to configure SSL page, and a number of other sites. The issue I'm having is that when my App starts, I get an exception that states that trustAnchors parameter must be non-empty. I tried tracking down that exception, and followed some advice to add a system property for javax.net.ssl.trustStore set to the filesystem path of my keystore file. This hasn't helped, unfortunately. Does anyone have any recommendations of other things I can try? Is there a specific location I should be storing my keystore file to have it found automatically? Or a different mechanism (file: URL?) that I need to use to specify its location? My code currently looks like this: String port = props.getProperty(web.port_number); int portNum = Integer.parseInt(port); String keystorePath = props.getProperty(web.keystore.path); System.setProperty(javax.net.ssl.trustStore, keystorePath); // Create a component with an HTTPS server connector Component comp = new Component(); comp.getClients().add(Protocol.FILE); Server httpsServer = comp.getServers().add(Protocol.HTTPS, portNum); SeriesParameter parameters = httpsServer.getContext().getParameters(); parameters.add(sslContextFactory, com.noelios.restlet.ext.ssl.PkixSslContextFactory); parameters.add(keystorePath, keystorePath); parameters.add(keystorePassword, myKeystorePw); parameters.add(keyPassword, myKeyPw); parameters.add(keystoreType, JKS); comp.getDefaultHost().attach(, new Application()); comp.start(); The exception(s) I'm getting are pasted in below for reference. Thanks for any suggestions! John Wismar mailto:john.wis...@autozone.com -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1769928
Re: Restlet and maven
Bruno Harbulot wrote: Rémi Dewitte wrote: Hello, I know there is some ongoing work about maven and restlet. If I checkout the trunk and build it, how do I install the new artifacts into my local m2 repository ? Assuming you're on a unix machine, I find the easiest to be: 1. Edit build/build.properties to set the maven option to 'true'. 2. cd build/dist/maven2/restlet-1.2snapshot 3. tar cf - . | tar xvf - ~/.m2/repository Sorry, I meant: tar cf - . | tar xvf - -C ~/.m2/repository -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1581688
Re: Restlet and maven
Rémi Dewitte wrote: Hello, I know there is some ongoing work about maven and restlet. If I checkout the trunk and build it, how do I install the new artifacts into my local m2 repository ? Assuming you're on a unix machine, I find the easiest to be: 1. Edit build/build.properties to set the maven option to 'true'. 2. cd build/dist/maven2/restlet-1.2snapshot 3. tar cf - . | tar xvf - ~/.m2/repository Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1578606
Re: Grizzly Https Server
Hi Sheshakiran, Are you looking for using Grizzly or Restlet with the Grizzly connector? In Restlet, SSL support has been harmonised using an SslContextFactory for all the connectors. It supports client-certificate authentication (provided your configure it with the trust store you require.) If it's for Grizzly only, I'd suggest posting to the Grizzly list. Coincidentally, I've just made a few suggestions for improvement in Grizzly, but these don't affect Restlet and its use of Grizzly. (Note that the default should work at least, that is, specifying the keystore/truststore using the usual javax.net.ssl.* system properties, in Grizzly and Restlet.) Best wishes, Bruno. srsk wrote: Hi, I am Sheshakiran, developer from one of the service based industry. I have a requirement to develop one Grizzly Asynhcronous Https Server, which would do Basic Authentication and HTTPCertificate validation. I found Http implementation of grizzly server, but i am not able to get sufficient information on Grizzly Https implementation. Any kind of help would be really appreciable. Https should accept inputs like 1) Username and Password and 2) Certificate details like i) Keystore ii) Trusted certificate iii) passwords for keystore and certificate iv) private key alias and private key password ... thanks .. Sheshakiran -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1578563
Re: CSS and HTTPS problem ...
Hi, Rob Heittman wrote: You'd have to change the CSS to also reference the images, etc. over https. The warning you describe will be triggered whenever you have an HTML page, delivered over https, that calls images, CSS, or javascript from another source, delivered over http. This isn't a Restlet thing ... it applies to any SSL Web server. Yes, I agree. Although it's possible to turn off this warning in Firefox I'd suggest to keep it on. In terms of site design, it's bad practice to mix HTTPS and plain HTTP content. I've recently found a security issue with a service we use (I believe the vendor is investigating the matter). Access to the whole site was supposed to be secure because it was served over HTTPS. However, one of the web pages was loading a JavaScript document, which was linking another JavaScript document, this time in plain HTTP. (Surprisingly enough, this second link was a plain HTTP URL only if Mac was in the user-agent header!) Even if this last request failed with a 404 status code (the document being actually only served over HTTPS), the request was made over plain HTTP and contained the authenticated session cookie. Therefore, someone intercepting that request would be able to hijack the session. I haven't looked at how IE behaves with mixed content, but the downside of Firefox warnings is that they are just warnings (you can't cancel the request: you can only realise it's too late). However, one neat Restlet thing that does help, is the Redirector feature. This is a bit advanced, but you can use the Redirector on your local web service to proxy these requests to the other server; this can be used to avoid such warnings and single-source issues, at the expense of some overhead in your web service and a responsibility to manage the security appropriately. +1 Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1499674
Re: HTTPS trustAnchors error
Hi Dan,
It looks like a bug in the code I wrote... I'm going to look into this.
Can you try using com.noelios.restlet.util.DefaultSslContextFactory
instead of com.noelios.restlet.ext.ssl.PkixSslContextFactory meanwhile?
Best wishes,
Bruno.
Dan Noble wrote:
Hello all,
I am new to Restlets, and I am trying to set up a simple server to accept
HTTPS connections. (I'm using Restlets 1.1.2, Java 1.6 on OSX 10.5 and my
classpath has the following jars:
com.noelios.restlet.ext.ssl.jar
org.jsslutils.jar
org.simpleframework.jar
com.noelios.restlet.jar
org.restlet.jar
com.noelios.restlet.ext.simple_3.1.jar)
I have been following:
http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet/213-restlet.html
To generate the keystore, i used:
keytool -genkey -v -alias serverX -keypass password -keystore serverX.jks
-keyalg RSA -sigalg MD5withRSA -keysize 2048 -validity 3650
and entered password for the keystore password for testing purposes.
Here is the code I have so far:
public static void main(String[] args) {
try {
// Create a new Component.
Component component = new Component();
// Add a new HTTPS server listening on port 8182.
Server server = component.getServers().add(Protocol.HTTPS, 8182);
SeriesParameter parameters =
server.getContext().getParameters();
File pwd = new File(.);
String path = pwd.getCanonicalPath();
String keystorePath = path + /keystore/serverX.jks;
parameters.add(sslContextFactory,
com.noelios.restlet.ext.ssl.PkixSslContextFactory);
parameters.add(keystorePath, keystorePath);
parameters.add(keystorePassword, password);
parameters.add(keyPassword, password);
parameters.add(keystoreType, JKS);
// Attach the sample application.
component.getDefaultHost().attach(,new
MessageForwarderApplication());
// Start the component.
component.start();
System.out.println(Started);
} catch (Exception e) {
// Something is wrong.
e.printStackTrace();
}
}
The exact exception is I'm getting is:
org.jsslutils.sslcontext.SSLContextFactory$SSLContextFactoryException:
Exception in SSLContextFactory
at
org.jsslutils.sslcontext.PKIXSSLContextFactory.getPKIXParameters(PKIXSSLContextFactory.java:231)
at
org.jsslutils.sslcontext.PKIXSSLContextFactory.getTrustParams(PKIXSSLContextFactory.java:190)
at
org.jsslutils.sslcontext.PKIXSSLContextFactory.getRawTrustManagers(PKIXSSLContextFactory.java:163)
at
org.jsslutils.sslcontext.X509SSLContextFactory.getTrustManagers(X509SSLContextFactory.java:346)
at
org.jsslutils.sslcontext.SSLContextFactory.buildSSLContext(SSLContextFactory.java:256)
at
com.noelios.restlet.ext.ssl.PkixSslContextFactory.createSslContext(PkixSslContextFactory.java:72)
at
com.noelios.restlet.ext.simple.HttpsServerHelper.start(HttpsServerHelper.java:267)
at org.restlet.Server.start(Server.java:383)
at org.restlet.Component.startServers(Component.java:1233)
at org.restlet.Component.start(Component.java:1194)
at
com.test.messageservice.MessageService.main(MessageService.java:55) // ---
component.start(); line
Caused by: java.security.InvalidAlgorithmParameterException: the trustAnchors
parameter must be non-empty
at
java.security.cert.PKIXParameters.setTrustAnchors(PKIXParameters.java:183)
at java.security.cert.PKIXParameters.init(PKIXParameters.java:140)
at
java.security.cert.PKIXBuilderParameters.init(PKIXBuilderParameters.java:113)
at
org.jsslutils.sslcontext.PKIXSSLContextFactory.getPKIXParameters(PKIXSSLContextFactory.java:215)
... 10 more
After a little bit of googling, it looks like this has something to do with
the trustStore... I tried setting the truststore using:
System.setProperty(javax.net.ssl.trustStore,/path/to/osx/cacerts);
System.setProperty(javax.net.ssl.trustStorePassword,changeit);
but received the same error.
If anyone has any insight, I would be most grateful!
Thanks,
Dan
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1065230
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1068636
Re: How to set the SSLContextFactory in the Client
Hi Chris,
Bruno Harbulot wrote:
Hi Chris,
christian.hai...@gmail.com wrote:
I use Restlet Version 1.1
I tried it this way:
Client client = new Client(new Context(), Protocol.HTTPS);
Context con = client.getContext();
SeriesParameter param1 = con.getParameters();
param1.add(sslContextFactory,MySSLContextFactory);
where MySSLContextFactory has the base class
com.noelios.restlet.util.SslContextFactory
But it is not working that way.
Can you clarify how it's not working?
There's more documentation here:
[1] http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet.html
[2] http://wiki.restlet.org/docs_1.1/13-restlet/28-restlet/153-restlet.html
There is a difference between using parameters and attributes when
setting the context (as mentioned in [1]).
When passing the settings via parameters, sslContextFactory must be a
class name, and you should also pass whatever other parameters your
SslContextFactory expects (I'm not sure what they are in your case).
This is more or less what's described in [2] for PkixSslContextFactory.
Most of the keyStore* parameters also work for the
DefaultSslContextFactory.
If you want to pass an SslContextFactory that has already been
configured (perhaps with more advanced options), you might want to pass
the instance via the sslContextFactory /attribute/ in the context, in
which case the value of the sslContextFactory /parameter/ will be ignored.
This could look like this, for example:
import org.jsslutils.sslcontext.PKIXSSLContextFactory;
import org.jsslutils.sslcontext.trustmanagers.GsiWrappingTrustManager;
final PKIXSSLContextFactory sslContextFactory = new
PKIXSSLContextFactory(..., ..., ...);
for (String crl : ...) {
sslContextFactory.addCrl(crl);
}
sslContextFactory.setTrustManagerWrapper(new
GsiWrappingTrustManager.Wrapper());
server.getContext().getAttributes().put(sslContextFactory,
new SslContextFactory() {
@Override
public SSLContext createSslContext() throws Exception {
return sslContextFactory.buildSSLContext();
}
@Override
public void init(SeriesParameter parameters) {
}
});
Sorry, I've just realised I had missed the point of the question: the
client (whereas my example is for a server).
SslContextFactories are not currently supported on the client side. For
more details, see:
http://restlet.tigris.org/issues/show_bug.cgi?id=586#desc4
There are ways around this. You can create an SSLContextFactory with
jSSLutils and create an SSLContext out of it.
If you're using Java 6 and the default Java connector, you can set this
SSLContext using SSLContext.setDefault(...).
If you're using the Apache HTTP client connector, use the method
described in issue #586, with this
http://code.google.com/p/jsslutils/wiki/ApacheHttpClientUsage
In both cases, the settings will be global for all your client connectors.
Best wishes,
Bruno.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1028330
Re: How to set the SSLContextFactory in the Client
Hi Chris,
christian.hai...@gmail.com wrote:
I use Restlet Version 1.1
I tried it this way:
Client client = new Client(new Context(), Protocol.HTTPS);
Context con = client.getContext();
SeriesParameter param1 = con.getParameters();
param1.add(sslContextFactory,MySSLContextFactory);
where MySSLContextFactory has the base class
com.noelios.restlet.util.SslContextFactory
But it is not working that way.
Can you clarify how it's not working?
There's more documentation here:
[1] http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/46-restlet.html
[2] http://wiki.restlet.org/docs_1.1/13-restlet/28-restlet/153-restlet.html
There is a difference between using parameters and attributes when
setting the context (as mentioned in [1]).
When passing the settings via parameters, sslContextFactory must be a
class name, and you should also pass whatever other parameters your
SslContextFactory expects (I'm not sure what they are in your case).
This is more or less what's described in [2] for PkixSslContextFactory.
Most of the keyStore* parameters also work for the
DefaultSslContextFactory.
If you want to pass an SslContextFactory that has already been
configured (perhaps with more advanced options), you might want to pass
the instance via the sslContextFactory /attribute/ in the context, in
which case the value of the sslContextFactory /parameter/ will be ignored.
This could look like this, for example:
import org.jsslutils.sslcontext.PKIXSSLContextFactory;
import org.jsslutils.sslcontext.trustmanagers.GsiWrappingTrustManager;
final PKIXSSLContextFactory sslContextFactory = new
PKIXSSLContextFactory(..., ..., ...);
for (String crl : ...) {
sslContextFactory.addCrl(crl);
}
sslContextFactory.setTrustManagerWrapper(new
GsiWrappingTrustManager.Wrapper());
server.getContext().getAttributes().put(sslContextFactory,
new SslContextFactory() {
@Override
public SSLContext createSslContext() throws Exception {
return sslContextFactory.buildSSLContext();
}
@Override
public void init(SeriesParameter parameters) {
}
});
Best wishes,
Bruno.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=1018944
Re: contributing - areas of interest
Hi, You might also be interested in RFE 505, which already has a few comments, including pointers to discussions on this mailing list: http://restlet.tigris.org/issues/show_bug.cgi?id=505 (I doubt I'll be able to follow the discussions in details over the next couple of weeks at least.) Best wishes, Bruno. Raif S. Naffah wrote: hello Avi, On Tuesday 09 December 2008 03:32:54 Avi Flax wrote: On Mon, Dec 8, 2008 at 03:04, Raif S. Naffah [EMAIL PROTECTED] raif.namewrote: i'd like to contribute to this project in my free time. Raif, that's great! Can I suggest RFE 658, Add support for JSecurity? http://restlet.tigris.org/issues/show_bug.cgi?id=658 Since you're interested in security, this might be interesting to you. I'd love to see this one make progress! yah! it's very close to what i had in mind. i'll look closer into JSecurity and may be add my comment to that RFE. Thanks, thanks for bringing JSecurity to my attention! Avi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=98 1192 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=981301
Re: Guard suggestion
Hi Stephan, Stephan Koops wrote: Hi Bruno, I think, in the context of wider refactorisation of authentication and authorisation, that authentication should provided a Principal when a client has been authenticated (and perhaps a default guest principal when no one has, like jGuard does, but that's a different matter). why not use null as guest principal? What is the advantage of an object for it? I don't think it's very significant. I was simply referring to what jGuard does: http://jguard.xwiki.com/xwiki/bin/view/Doc/Faq#HAccessFilterautomaticallytriestologmeinas27guest27Whyshouldtherebea22default22userinjGuard3FIsn27tthatasecurityissue3F Best wishes, Bruno.
Re: Guard suggestion
Hi Jerome and Remi,
I think, in the context of wider refactorisation of authentication and
authorisation, that authentication should provided a Principal when a
client has been authenticated (and perhaps a default guest principal
when no one has, like jGuard does, but that's a different matter).
Then, when authorise should take that Principal and choose
whether-or-not to authorise depending on that value. The case you
describe seems to correspond to a null/guest value, which is fine.
Best wishes,
Bruno.
Jerome Louvel wrote:
Hi Rémi,
Thanks, I've added your use case as a comment in the RFE.
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/
*De :* Rémi Dewitte [mailto:[EMAIL PROTECTED]
*Envoyé :* lundi 24 novembre 2008 14:35
*À :* discuss@restlet.tigris.org
*Objet :* Re: Guard suggestion
Hello,
For example you have an application where you want to display various
informations with different levels of information.
There is an interface to manage rules for authorizations. One of the
rule could be to authorize all users to access the resource or only
authorized or only specific users, etc.
It is up to the authorize method to trigger 401 responses...
Rémi
On Tue, Nov 18, 2008 at 09:34, Jerome Louvel [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi Rémi,
I have added your suggestion to the RFE mentioned by Stephan:
Refactor authentication and authorization
http://restlet.tigris.org/issues/show_bug.cgi?id=505
Do you have examples in mind where it would be nice to authorize
unauthenticated client requests ?
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/
*De :* [EMAIL PROTECTED] mailto:[EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] mailto:[EMAIL PROTECTED]] *De la
part de* Rémi Dewitte
*Envoyé :* vendredi 14 novembre 2008 23:27
*À :* discuss@restlet.tigris.org mailto:discuss@restlet.tigris.org
*Objet :* Re: Guard suggestion
It would also let the autorize() method to decide whether
AuthenticationMissing forbids the response or not.
For a resource, authorized clients might have more details for example.
Rémi
On Fri, Nov 14, 2008 at 21:17, Stephan Koops [EMAIL PROTECTED]
mailto:[EMAIL PROTECTED] wrote:
Hi Rémi,
You mean, that a client can authorize himself, but it is not
required? I think this is a good ideas. For browser applications
I don't now, if browsers could work with this.
The authentication should be reworked in the near future (I
don't know te current timetable for this). If your proposal is
missing then, throw it into the discussion again.
best regards
Stephan
Rémi Dewitte schrieb:
Hello all,
Let me make a suggestion about the Guard class.
It would allow the authorize method to make a decision even
if no authentication is present.
Why not adding an authorizeMissing attribute and change
handling of AUTHENTICATION_MISSING in doHandle method
from
challenge(response, false);
to
if(isAuthorizeMissing() authorize(request)){
accept(request, response);
}else{
challenge(response, false);
}
Cheers,
Rémi
Re: Well HTTPS
Hi,
Ben Johnson wrote:
Hi
I am new to Restlet and web programming, HTTP and SSL certificates in
general, but hopefully my recent experiences will help. I spent the
last several days trying to find a Restlet example using HTTPS (there
isn't one), and eventually pieced together the following (using Windows
XP SP2 with Java 6, Eclipse, Restlet 1.1.1):
1) Create your keys and certificate. I tried both 'keytool' and IBM's
KeyMan to do this (KeyMan is easier, but more work to obtain, as you
need to register, etc...). Using keytool from a command prompt you need
to enter two commands - the first one creates the keystore file with the
keys, the second certifies it (self-certification, ok for testing). The
most important thing is that the name of the machine you will be using
the certificate on matches what you specify (in the example below, my
machine is called 'serverX'):
keytool -genkey -dname CN=serverX, OU=IT, O=JPC, C=GB -alias serverX
-keypass password -keystore serverX.cer -storepass password -keyalg
RSA -storetype PKCS12 -provider sun.security.provider.Sun
keytool -selfcert -alias serverX -keystore serverX.cer -storepass
password -storetype PKCS12
The keystore file has now been created and self-certified: in this
example it is called 'serverX.cer' and was saved in the current
directory. There are two passwords: one for the keys and one to access
the keystore. I set them both to 'password' for testing. The name of
the keystore file ('serverX.cer') is not important, I just used that for
consistency.
Usually, the extension for JKS keystores is jks and the extension for
PKCS#12 keystores is p12. cer tends to be used for X.509
certificates in DER format (application/x-x509-ca-cert), which are files
containing just the certificate: this is the format produced by keytool
-export.
It looks from the example below that you've used jks for that, whereas
it's not actually a JKS file but a cer file.
2) To prevent warnings in a browser, add the keystore to the 'Trusted
Root Certification Authorities' on your computer. In Windows XP, I just
used Internet Options (via IE7 or Control Panel - Internet Options). On
the 'Content' tab, click 'Certificates', then go to 'Trusted Root
Certification Authorities' tab, click 'Import...' and follow the steps
to import your keystore file (in my example, 'serverX.cer'). It will
give warnings about not being verified, which is ok for testing (but
it must be properly signed for production).
Since your .cer is in fact a .p12, this might import the private key as
well (that's what you would do if you wanted to use client-certificate
authentication). In fact, the actual .cer exported by keytool should be
sufficient. Just to clarify the extensions:
keytool -export -alias serverX -file serverX.cer -storetype PKCS12
-keystore serverX.p12 -keypass password
(Shouldn't this be -storepass rather than -keypass by the way?)
3) In order for Java security to recognise the certificate, it needs to
be added to JRE\lib\security\cacerts, which is the Java certificates
file. This is important when you use a Restlet client to connect to the
server via HTTPS (but it did not seem to be needed by my browser - it
needed the IE options update described in point 2). On my
system, 'cacerts' is C:\Program Files\Java\jre6\lib\security\cacerts.
I had some trouble adding my 'serverX' certificate to it, but the
following keytool commands work if you know the password for cacerts
('changeit' is the default I believe):
keytool -export -alias serverX -file serverX.jks -storetype PKCS12
-keystore serverX.cer -keypass password
keytool -import -alias serverX -file serverX.jks -noprompt -trustcacerts
-keystore C:\Program Files\Java\jre6\lib\security\cacerts
The first command exports the certificate from PKCS12 format into X.509
(JKS) format, which is what cacerts needs. In my case, I had to use
KeyMan to set the password for the 'cacerts' file (I set it back to the
default of 'changeit'), so when I ran 'keytool -import ...' I could
enter the correct password. There may be a better/easier way to do this.
If for some reason, you can write to that file (which is likely to be
shared by all users on that system), you can specify your own truststore
using -Djavax.net.ssl.trustStore=mytruststore.jks
-Djavax.net.ssl.trustStore=JKS
-Djavax.net.ssl.trustStorePassword=ABCDEFGH as JVM parameters.
If you're requiring client-authentication (in which case it makes sense
to set up a trust store on the server), you can used the truststorePath,
truststorePassword and truststoreType parameters of the Restlet Server
when you're using the sslContextFactory (as you've done below).
There's currently no SSLContextFactory support in the client connectors
of Restlet, so you'll have either to modify the central cacerts as you
did, or use the SSL system properties.
As a side note, the C:\Program Files\Java\jre6\lib\security\cacerts is
the set
Re: Well HTTPS
Hi, I'm not sure you're clear on what certificates, signing and encryption are. Roughly speaking, an X.509 certificate is the combination of a public key and some information (subject distinguished name, date from/to, other attributes) that has been signed using a private key usually corresponding to another certificate. The signer (CA) asserts authority on the validity of the information in this certificate by signing it, but the certificate itself is not enciphered and it's meant to be public. The certificate of the signer (corresponding to its private key) may be an intermediate CA or a root CA certificate. In the latter case, it's a self-signed certificate (which means that it's been signed with its own private key). Why would you trust such a CA certificate? That's a leap of faith. Browsers and operating systems come with a bundle of CA certificates they trust by default (Verisign, Thawte, ...), but you could have your own PKI and set your own within your organisation. As Ben pointed out in another message on this thread, the default set of trusted CA certificates in the JVM is in a file called cacerts. It's however up to you to make sure you want to trust the CA certificates it contains. Similarly IE, Firefox, OSX Keychain come with their set of trusted CAs. The only reasons you'd trust them are: - you trust the copy of the software you've obtained is genuine, and - you trust the company/organisation that produced that software to have made the right choices, because it has bundled the CA certificates it wanted you to have. Best wishes, Bruno. Mohammed Al-Adawi wrote: Hi Given X = Public key and some data; Trusted Certificate is X which is digitally signed by CA private key. Digitally signed means hashing X and then encrypt it with CA private key. if that is true CA public key must be some where and NOT encrypted so you can decrypt certificate, You can say that I have an emotional problem coming from the fact: NO ONE said that CA public key is there available, also no one said where it is stored!! keystore, truststore, or it is not encrypted nor hashed. Can you solve my emotional problem?? Thanks
Re: client-side support for Negotiate authentication scheme
Hi Roman and Jerome, Sorry for the delay. I've just added the tarball to the issue tracker: http://restlet.tigris.org/issues/show_bug.cgi?id=444 Best wishes, Bruno. Jerome Louvel wrote: Hi Bruno, I would suggest that you attach a zip with your source code to the existing issue in the tracker (or a new one). Once, we create the 1.1 branch, we could use the trunk to land this but it is a bit premature for now. Best regards, Jérôme Louvel -- Restlet ~ Founder and Lead developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com -Message d'origine- De : news [mailto:[EMAIL PROTECTED] De la part de Bruno Harbulot Envoyé : mercredi 1 octobre 2008 12:50 À : discuss@restlet.tigris.org Objet : Re: client-side support for Negotiate authentication scheme Hi all, I'd be happy to put it in the Restlet repository. Jerome, do you have any preferred place in the repository for this? By the way, I had mentioned I had started some work on the structure of the Guards, etc. (mostly for my project's needs but that could be used for 1.2). Perhaps it could be time to put it somewhere in the Restlet code-base too. I was going to wait for the 1.1 release, but if Roman is doing some work on this type of problem too, we might as well try to coordinate our work. Best wishes, Bruno. Roman Geus wrote: Hi Jerome Thanks for pointing out the necessary steps. I'll wait until Bruno's code has been contributed to the repository and then do my part. Best regards, Roman Jerome Louvel wrote: Hi Roman, Bruno and all, Roman, thanks for reporting this parsing bug with WWW-Authenticate HTTP header. I have just fixed it in SVN trunk. Regarding the support for SPNEGO, I've updated the related RFE with a link to Bruno's original filter and another one back to this thread. I've also changed the target milestone of this RFE to 1.2 as it seems there is a good chance we could effectively add support for it. Support SPNEGO authentication http://restlet.tigris.org/issues/show_bug.cgi?id=444
