Re: SSL needClientAuthentication not working

2011-11-30 Thread Bruno Harbulot
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?

2011-11-30 Thread Bruno Harbulot
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

2010-11-03 Thread Bruno Harbulot
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

2010-09-22 Thread Bruno Harbulot
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

2010-09-17 Thread Bruno Harbulot
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

2010-09-15 Thread Bruno Harbulot
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

2010-08-25 Thread Bruno Harbulot
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

2010-08-25 Thread Bruno Harbulot
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

2010-08-25 Thread Bruno Harbulot
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

2010-08-25 Thread Bruno Harbulot
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

2010-08-25 Thread Bruno Harbulot
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)

2010-08-09 Thread Bruno Harbulot
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()

2010-08-06 Thread Bruno Harbulot
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

2010-08-03 Thread Bruno Harbulot
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

2010-08-03 Thread Bruno Harbulot
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

2010-07-28 Thread Bruno Harbulot
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

2010-06-28 Thread Bruno Harbulot
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

2010-06-24 Thread Bruno Harbulot
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

2010-06-10 Thread Bruno Harbulot
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

2010-06-09 Thread Bruno Harbulot
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

2010-06-08 Thread Bruno Harbulot
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

2010-06-03 Thread Bruno Harbulot
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

2010-05-20 Thread Bruno Harbulot
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

2010-05-19 Thread Bruno Harbulot
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

2010-05-18 Thread Bruno Harbulot
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

2010-05-14 Thread Bruno Harbulot
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

2010-05-10 Thread Bruno Harbulot
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

2010-05-10 Thread Bruno Harbulot
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

2010-05-06 Thread Bruno Harbulot
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

2010-05-06 Thread Bruno Harbulot
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 ?

2010-05-04 Thread Bruno Harbulot
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 ?

2010-04-30 Thread Bruno Harbulot
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 ?

2010-04-27 Thread Bruno Harbulot
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 ?

2010-04-26 Thread Bruno Harbulot
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 ?

2010-04-26 Thread Bruno Harbulot
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

2010-03-26 Thread Bruno Harbulot
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

2010-03-25 Thread Bruno Harbulot
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

2010-03-25 Thread Bruno Harbulot
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

2010-03-25 Thread Bruno Harbulot
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

2010-03-25 Thread Bruno Harbulot
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

2010-03-17 Thread Bruno Harbulot
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

2010-03-16 Thread Bruno Harbulot
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?

2010-03-15 Thread Bruno Harbulot
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

2010-03-15 Thread Bruno Harbulot
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 ...

2010-03-03 Thread Bruno Harbulot
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)

2010-03-02 Thread Bruno Harbulot
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

2010-02-26 Thread Bruno Harbulot
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 ...

2010-02-25 Thread Bruno Harbulot
Hi,

Stefan Meissner wrote:
 Hi,
 
 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). 
 
 I was afraid it's not the same. What I need is an equivalent to: 
 'javax.servlet.request.ssl_session'
 
 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).
 
 If I print out the pure ID out of the byte array I get this: [...@e51b2c 
 which looks like an hex address to me. How can I get to the value then?

Not sure how much experience you have with Java, but it doesn't really 
have the notion of addresses. [...@e51b2c is just the default output of 
toString() on an array object:
http://java.sun.com/j2se/1.5.0/docs/api/java/lang/Object.html#toString()

I'd suggest searching for Java byte array to hex conversion if you want 
an string representing the values in your array in hexadecimal (same 
format as used by javax.servlet.request.ssl_session).


 Anyway, in many of the cases of request there is no ID available at all. 
 That's why I also think the SSL session context is not approriate here.

As I said, it's not absurd want to expose the SSL session ID as a 
Request parameter (in the same was as client certificates and cipher 
suites are exposed). I could try to provide a patch to do so (if Jerome 
and Thierry are happy with it).

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.


Best wishes,

Bruno.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2452041


Re: Access to HttpSession from Restlet ...

2010-02-25 Thread Bruno Harbulot
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 ...

2010-02-24 Thread Bruno Harbulot
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

2010-02-11 Thread Bruno Harbulot
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

2010-02-10 Thread Bruno Harbulot
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

2010-02-10 Thread Bruno Harbulot
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

2010-02-04 Thread Bruno Harbulot
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

2010-01-22 Thread Bruno Harbulot
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

2010-01-20 Thread Bruno Harbulot
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?

2009-12-16 Thread Bruno Harbulot
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

2009-12-04 Thread Bruno Harbulot
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

2009-12-03 Thread Bruno Harbulot
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

2009-11-30 Thread Bruno Harbulot
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

2009-11-23 Thread Bruno Harbulot
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

2009-11-17 Thread Bruno Harbulot
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

2009-10-29 Thread Bruno Harbulot
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

2009-10-17 Thread Bruno Harbulot
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

2009-09-23 Thread Bruno Harbulot
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

2009-09-22 Thread Bruno Harbulot
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

2009-09-18 Thread Bruno Harbulot
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

2009-09-17 Thread Bruno Harbulot
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

2009-09-17 Thread Bruno Harbulot
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

2009-08-21 Thread Bruno Harbulot
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

2009-08-20 Thread Bruno Harbulot
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

2009-08-20 Thread Bruno Harbulot
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

2009-08-19 Thread Bruno Harbulot
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

2009-08-14 Thread Bruno Harbulot
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)

2009-07-20 Thread Bruno Harbulot
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)

2009-07-17 Thread Bruno Harbulot
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)'

2009-07-17 Thread Bruno Harbulot
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

2009-07-14 Thread Bruno Harbulot
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?

2009-06-25 Thread Bruno Harbulot
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?

2009-06-24 Thread Bruno Harbulot
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

2009-06-12 Thread Bruno Harbulot
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

2009-06-12 Thread Bruno Harbulot
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

2009-06-12 Thread Bruno Harbulot
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

2009-06-11 Thread Bruno Harbulot
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

2009-05-08 Thread Bruno Harbulot
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

2009-05-06 Thread Bruno Harbulot
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

2009-05-06 Thread Bruno Harbulot
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

2009-04-17 Thread Bruno Harbulot
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

2009-04-08 Thread Bruno Harbulot
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

2009-04-08 Thread Bruno Harbulot
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

2009-04-08 Thread Bruno Harbulot
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 ...

2009-04-01 Thread Bruno Harbulot
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

2009-01-29 Thread Bruno Harbulot
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

2009-01-16 Thread Bruno Harbulot
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

2009-01-12 Thread Bruno Harbulot
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

2008-12-08 Thread Bruno Harbulot
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

2008-11-27 Thread Bruno Harbulot

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

2008-11-26 Thread Bruno Harbulot

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

2008-11-21 Thread Bruno Harbulot

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

2008-11-21 Thread Bruno Harbulot

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





  1   2   >