Re: HTTPS server

[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.(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.(PKIXParameters.java:140)
>  at 
> java.security.cert.PKIXBuilderParameters.(PKIXBuilderParameters.java:113)
>  at 
> org.jsslutils.sslcontext.PKIXSSLContextFactory.getPKIXParameters(PKIXSSLContextFactory.java:215)
>  ... 11 more
>
> --
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=2647748
>

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

Re: restlets : communicating in SSL with tomcat

[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", "mycacerts.jks");
parameters.add("truststorePassword", "password");
// parameters.add("truststoreType", "JKS");



Best wishes,

Bruno.

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

Re: Embedded Jetty

[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=4447&dsMessageId=2660271

Re: Embedded Jetty

[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=4447&dsMessageId=2661225

Re: SAML 2.0 with Restlet

[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=4447&dsMessageId=2663337

Re: An unexpected status was returned: Communication Error (1001) - sun.security.validator.ValidatorExce

[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(Series 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=4447&dsMessageId=2677857

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

Re: Client Authentication SSL using Jetty

[Bruno Harbulot]

On 28/11/2011 12:16, David C wrote:
> Hi
>
> As it turned out. The problem was that setting the trust information lies 
> outside the restlet framework. Adding these two lines solved the user 
> authenticaiton problem using SSL for me.
>
>  System.setProperty("javax.net.ssl.trustStore", keystorepath);
>  System.setProperty("javax.net.ssl.trustStorePassword", 
> keystorepassword);
>

Setting the trust information can be done for a specific connector, 
without necessarily relying on the global properties.
Have you tried to set the server parameter using "truststorePath", not 
"truststore" as you've used?

Best wishes,

Bruno.

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

Re: SSL needClientAuthentication not working

[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=4447&dsMessageId=2889303

Re: What is the importantce of passwords when configuring HTTPS?

[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=4447&dsMessageId=2889304

Client X509Certificate attribute using the AJP connector

[Bruno Harbulot]

Hello,

Using Servlets and Tomcat behind Apache Httpd/AJP (configured to require 
or want a client certificate in HTTPS), it's possible to get the client 
certificate chain using this:

  request.getAttribute("javax.servlet.request.X509Certificate");

I've tried to get this piece of information with a Restlet (using AJP), 
but this attribute doesn't seem be set. This is hardly surprising 
because of "servlet" in the name, but I can't find any equivalent 
attribute. Is there any other mechanism to get this from a Request?


Best wishes,

Bruno.

Re: Client X509Certificate attribute using the AJP connector

[Bruno Harbulot]

Hello Jérôme,

I'm using the Jetty AJP connector directly. I haven't tried the 
ServerServlet yet, so I'm not sure what information it passes through.
Another thing I would be interested in is to get the remote user, as 
authenticated by Apache Httpd. This is something servlets can get using 
Jetty or Tomcat (provided they are configured accordingly).
I'm quite new to Restlets, but I had in mind it could be useful to get 
the client X.509 certificate and/or the remote user in a Guard that 
would perform the authorisation.


Best wishes,

Bruno.

Jerome Louvel wrote:

Hello Bruno,

Are you using the ServerServlet adapter class or directly the Jetty
AJP connector with Restlet ?

Thanks,
Jerome

2007/11/2, Bruno Harbulot <[EMAIL PROTECTED]>:

Hello,

Using Servlets and Tomcat behind Apache Httpd/AJP (configured to require
or want a client certificate in HTTPS), it's possible to get the client
certificate chain using this:
   request.getAttribute("javax.servlet.request.X509Certificate");

I've tried to get this piece of information with a Restlet (using AJP),
but this attribute doesn't seem be set. This is hardly surprising
because of "servlet" in the name, but I can't find any equivalent
attribute. Is there any other mechanism to get this from a Request?

Best wishes,

Bruno.

Re: Client X509Certificate attribute using the AJP connector

[Bruno Harbulot]

Hi Jerome,

Regarding Jetty, AJP and the client certificates, I submitted a patch a 
couple of days ago for Jetty, as there was a small bug:

http://jira.codehaus.org/browse/JETTY-457
I'm please to say Greg Wilkins (Jetty) has already incorporated the 
changes in Jetty 6.1.6rc1.


I'll try to provide more details and examples later on this week. I've 
just spotted a thread on this list about 2-way certificate 
authentication which seems relevant.


Bruno.


Jerome Louvel wrote:

Hi Bruno,

Thanks for the details. Do you have pointers to how this mechanism precisely
works in Tomcat and/or Jetty?

Also, if you could open an RFE and summarize our discussion that would be a
good step forward.

Best regards,
Jerome  

Reaching target Resources that do not exist

[Bruno Harbulot]

Hello,

I'd like to model resources using Restlet in a similar way as Section 12 
of the tutorial ("Reaching target Resources"). As a simple example, I'd 
like to map URIs like "/users/{user}/birthday" to read the full name of 
a user from a database (or hash-table).


As far as I understand the tutorial, I can create a Resource class (for 
example BirthdayResource) that reads the username from the attribute in 
the constructor and reads the birthday from the database. Then, it can 
attach it to the router using something like this:

   router.attach("/users/{user}/birthday", BirthdayResource.class);
The problem is that some username values might not be in this database, 
in which case I'd like to return a "NOT FOUND" response.


Where is the right place to look whether-or-not the resource actually 
exists? Shouldn't this be done before the Resource instance is created?

Where does this fit in the router/attach model?

Best wishes,

Bruno.

Re: Client X509Certificate attribute using the AJP connector

[Bruno Harbulot]

Hi Jerome,


I haven't tried any code yet, but I think I found what was going on by 
looking at some of the code. What I'm talking about is related to the 
first modification mentioned in

http://restlet.tigris.org/issues/show_bug.cgi?id=281
(using getPeerCertificates()).

When using servlets, the specification states that client certificates 
should be presented in attribute "javax.servlet.request.X509Certificate" 
as a java.security.cert.X509Certificate[] (Section 5.7 of spec 2.2 and 
Section SRV.4.7 of spec 2.3).
I think the modification made to use getPeerCertificates() aimed to 
achieve this, by putting this information in attribute 
"org.restlet.https.clientCertificates" of a Restlet Request. (Out of 
curiosity, why use a List and not an array? Although Restlets are not 
Servlets, it might have made porting some code a bit easier. I don't 
think it really matters, though.)


By looking at the current code in SVN, this feature seems to be 
implemented in com.noelios.restlet.http.HttpServerConverter (method 
toRequest).
Unfortunately, this relies on HttpServerCall.getSslSession(), which is 
implemented in SimpleCall, but not JettyCall (which I believe is the one 
used by AJP). Perhaps this is not quite the right place to abstract 
this. Indeed, when using Jetty directly or AJP (or the ServletCall I 
guess), the HttpServerCall does not get to see the SslSession, but the 
relevant information regarding the client certificate can still be exposed.
I reckon it should be possible to convert the content of Servlet Request 
attribute "javax.servlet.request.X509Certificate" into 
"org.restlet.https.clientCertificates" when using these other connectors.



To be more specific regarding AJP, the mod_jk configuration of Apache 
Httpd is at: http://tomcat.apache.org/connectors-doc/reference/apache.html

In particular, to pass the chain of certificate, this should be used:
  JkOptions +ForwardSSLCertChain


Passing this from the AJP connection to the servlets is done in Jetty in 
this file: 
https://svn.codehaus.org/jetty/jetty/trunk/extras/ajp/src/main/java/org/mortbay/jetty/ajp/Ajp13Connection.java


All I've just mentioned is about the SSL certificate attributes, but I 
guess it could be useful to expose the SSL cipher, which is String in 
"javax.servlet.request.cipher_suite". The servlet spec version 2.3 also 
defines "javax.servlet.request.key_size", which should be an Integer. 
I'm not sure from which specification the 
"javax.servlet.request.ssl_session" attribute comes from, but it's in 
the Jetty code mentioned above.



The other piece of information that would be interesting to get 
(especially the context of AJP and probably Servlets) is the remote user.
Servlets have a getRemoteUser() method which returns a String. This is 
visible via Apache-Httpd -> AJP -> Jetty (and Tomcat, if 
tomcatAuthentication is disabled in its AJP configuration, see 
http://tomcat.apache.org/tomcat-6.0-doc/config/ajp.html ).
This is useful for delegating the authentication task to existing 
modules of Apache Httpd (which is also something I'm looking into, aside 
from certificates).
Unfortunately, as far as I know, Restlet Requests do not have a 
getRemoteUser() method. Perhaps it would be a good idea to pass this, 
when it exists, as another attribute, say "org.restlet.remote_user"? I 
guess it could be used by other protocols than HTTP/HTTPS.



I could try to write a patch, but since it may modify the API (or at 
least the interfaces), it might be better if someone more experienced 
with the code does it. I'm going to copy and paste all this in an RFE. I 
hope this clarifies what I was trying to get in the first place.



Thank you,

Bruno.


Bruno Harbulot wrote:

Hi Jerome,

Regarding Jetty, AJP and the client certificates, I submitted a patch a 
couple of days ago for Jetty, as there was a small bug:

http://jira.codehaus.org/browse/JETTY-457
I'm please to say Greg Wilkins (Jetty) has already incorporated the 
changes in Jetty 6.1.6rc1.


I'll try to provide more details and examples later on this week. I've 
just spotted a thread on this list about 2-way certificate 
authentication which seems relevant.


Bruno.

Re: Client X509Certificate attribute using the AJP connector

[Bruno Harbulot]

Bruno Harbulot wrote:

I could try to write a patch, but since it may modify the API (or at 
least the interfaces), it might be better if someone more experienced 
with the code does it. I'm going to copy and paste all this in an RFE.


Here it is:
http://restlet.tigris.org/issues/show_bug.cgi?id=376

Best regards,

Bruno.

Re: Reaching target Resources that do not exist

[Bruno Harbulot]

Hi Thierry,

Thierry Boileau wrote:

on one hand, you define a "route" which binds all uris such as
"/users/{user}/birthday" to a new instance of the BirthdayResource
class.
On the other hand, the resource is in charge to perform the request,
that is to say return a representation (if any) in case of "GET"
requests, delete the resource in case of "DELETE" request, etc. The
resource knows what happens and what to do.


I see. So I guess it would be fair to consider that the Resource object 
is more or less the equivalent of a closure representing the dispatch of 
a request to the resource.




In your case, the birthday resource is responsible to get the user (if
any), and return a representation of the user's birthday only if the
user exists. For example:
  1- the BirthdayResource constructor looks for the user and store it
as an attribute
  2- the "getRepresentation(Variant)" method returns a representation
only if the user attribute is not null


I think I found my mistake. In Resource.handleGet(), it's the fact there 
isn't any Variant that leads to a CLIENT_ERROR_NOT_FOUND response 
status. However, I was using this in the constructor, whether-or-not the 
resource existed:

  getVariants().add(new Variant(MediaType.TEXT_PLAIN));
Therefore, I shouldn't add any variant before I've made sure the 
resource exists.


If a transactional database is used in the back-end, I suppose that 
adding the Variants ought to be done as part of the transaction that 
reads or write data corresponding to the Resource. Such a transaction 
could be in the constructor of the Resource.




I hope this will help you.

Yes, cheers.


Do you expose a lot of attributes such as "birthday"?


Not really at the moment, that was just an example. As you can guess 
from my questions, I'm still learning about the framework. I have a 
REST-based model in mind for my application that I would have 
implemented with servlets, by I thought I'd be good to investigate restlets.
So far, so good, but I'm not sure I'll use the Resource part of the 
framework. I'm indeed planning to make a lot of short requests and I'm a 
bit concerned about creating a new instance of a Resource for every 
request in terms of performance. I guess using a Restlet directly might 
be more efficient in some cases.



Best regards,

Bruno.

Re: [n00b] Meta data around representation

[Bruno Harbulot]

xasima wrote:

Jerome Louvel  noelios.com> writes:



Hi there,If you don't want to add those to the XML representation/document,

you can create a subordinate resource to will handle those
metadata./path/document/345  -> URI of the document resource

/path/document/345/about -> URI of the metadata about the parent documentBest
regards,Jerome 



Or / and  use the custom headers, doesn't it? 



I think it depends on what you call "metadata". Indeed, some data may be
metadata with respect to a given document, but be "core" data from
another point of view. This is why it could be modelled under its own
resource, as Jerome said.
I don't think putting a lot of custom headers sounds like the right
thing to do. Perhaps you could have a custom header that points to your
metadata, for example:

(Request)
GET /path/document/345 HTTP/1.1
Host: example.org

(Response)
HTTP/1.1 200 OK
Date: Thu, 08 Nov 2007 17:06:05 GMT
Server: Noelios-Restlet-Engine/1.0.5
Content-Type: application/xml
X-Metadata-Location: http://example.org/path/document/345/about


Then, you would get the metadata from this other URI.


You could also imagine some sort of version system if you need strict
consistency in case of concurrent access. Let's suppose the metadata
contains the title of the document.

One of the problems you may encounter would be:
1. Client A gets /path/document/345 (and reads from the header where to
get the metadata from (but doesn't do it yet): /path/document/345/about)
2. Client B modifies /path/document/345 and this changes the title, thus
affects /path/document/345/about.
3. Client A gets /path/document/345/about

In this case, the representation client A gets from
/path/document/345/about could be out of sync with the representation
obtained from /path/document/345. Client A may have thus obtained a
document and its metadata which would have two different title valus.

I think one way to solve this would be to keep some sort of version on
the "about" resource, by creating a new resource every time a change
relative to the main document is made.
Thus, if a change to the document affects the metadata, you change the
URI to the metadata you would return by the system. In the same example
as before, this could be:
1. Client A gets /path/document/345 (and knows from the header that the
metadata is at /path/document/345/about/20)
2. Client B modifies /path/document/345, this creates
/path/document/345/about/21 for use in subsequent GETs
3. Client A gets /path/document/345/about/20, which is in sync with the
representation it got during the first step.

You could also have /path/document/345/about redirect to whichever
current version is the latest, but I think it wouldn't really matter,
unless the /path/document/345/about URI meant something in the rest of
the system (in particular, if it was linked from somewhere).

Whether-or-not you need to implement something to deal with such
concurrent queries surely depends on your application and what
concurrency constraints you have. It does not always matter if it's out
of sync, what matters is that your application knows it may be.


Best wishes,

Bruno.

Re: problem serving up mp4 video for iphone

[Bruno Harbulot]

Hello,

Andy Roberts wrote:
My REST service has to also serve static mp4 video files - for use on an 
iPhone.  I'm having problems where the iPhone won't play the video files 
when I call an open() command on the file URL which is located in the 
static content area of my restlet application.
 
My URL is targeting the /data resource and is of the form 
http://.../data/videos/jetman_4.mp4

[...]

streamApplication.getTunnelService().setEnabled(true);
streamApplication.getTunnelService().setMethodTunnel(true);
streamApplication.getTunnelService().setMethodParameter("method");
streamApplication.getMetadataService().addExtension("mp4", 
MediaType.VIDEO_MPEG);


I haven't tried, but this doesn't seem to be the appropriate media type 
for mp4. I'd try MediaType.valueOf("video/mp4") instead of 
MediaType.VIDEO_MPEG (which I presume is "video/mpeg"). This might match 
the content-type the iPhone is looking for.



Best wishes,

Bruno.

Re: Problems extracting a POST request's entity

[Bruno Harbulot]

Hi,

I've had a similar problem. Yesterday, just before 1.1M2 was released, I 
upgraded my application from Restlet 1.0.6 to 1.1M1. The POST requests 
stopped working.


I wrote a few tests to try to find where the problem was.
Using either the Apache HttpClient lib directly or Restlet, the clients 
were sending something like this:


   Request request = new Request(Method.POST, uri);
   request.setEntity("xmlns='http://example.org/test'>Hello", MediaType.APPLICATION_XML);



On the server side, I was using something like this ('post' or 
'acceptRepresentation'):


public void acceptRepresentation(Representation entity) {
try {
System.out.println("entity.isAvailable():
System.out.println("Document: "+entity.getText());
} catch (Exception e) {
throw new RuntimeException(e);
}
}

This would just print:
  entity.isAvailable(): true
  Document:

The main task I wanted to do was along these lines:

public void acceptRepresentation(Representation entity) {
try {
DocumentBuilderFactory dbf = 
DocumentBuilderFactory.newInstance();
dbf.setNamespaceAware(true);
DocumentBuilder db = dbf.newDocumentBuilder();
Document domDoc = db.parse(entity.getStream());
System.out.println("Document: "+domDoc);
} catch (Exception e) {
throw new RuntimeException(e);
}
}

This produced this exception:
  SEVERE: Unhandled exception or error intercepted
  java.lang.RuntimeException: org.xml.sax.SAXParseException: Premature 
end of file.

  ...


Additionally, both with Representation.getText() and 
Representation.getStream(), the result was not only empty but much 
slower than it was with Restlet 1.0.6. I guess there might have been 
something wrong with the way Grizzly handles the IO, it was probably 
blocking and then timing out when it shouldn't have.
This was on a Mac (OSX 10.5) and Restlet 1.1M1 was picking up the 
Grizzly server. If I removed Grizzly from the classpath, it would pick 
up Jetty and work fine.



To be honest, I didn't have time to investigate this much further, as 
upgrading to 1.1M2 solved the problem, even with Grizzly.



Which version of Restlet are you using, on which platform? Is it picking 
up Grizzly too?



Best wishes,

Bruno.



Sergio Saugar wrote:

Hi all,

  I'm developing a web-based middleware (the software of my PhD) and I'm
trying to use RESTLET. I create a server (and a client) and some
restlets to implement the execution dynamics of  my software.

  I'm using XML for the representation of the resources (using JAXB).

  Well, I tried to implement a GET method and it works, it returns a
response with a XML entity on it. But now I'm programming a POST method
and I have a problem. I create a request with a XML string as an entity
and it seems to be ok (I'm using a StringRepresentation) for this
purpose. The code that I use is one of the following:

Representation rep = new StringRepresentation(xmlString,
MediaType.TEXT_XML);

  I debug the request and it seems to be well formed. But, when I try to
get back the XML string on the handlePost method, I allways obtain a
null value. How could I extract the XML String from a request's
entity??? (i try to do it using an InputStreamReader but the result is
the same)

I would appreciate some help regarding this, it takes me two days!! :-)


P.D.- Please forgive my poor english :-)

Issue 376

[Bruno Harbulot]

Hello,

I'm interested in trying to contribute to solve issue 376:
http://restlet.tigris.org/issues/show_bug.cgi?id=376

There are in fact two sub-problems in this issue: (1) exposing 
javax.servlet.request.X509Certificate and (2) defining something that 
would provide the equivalent of 
javax.servlet.http.HttpServletRequest.getRemoteUser().


Is someone already working on it? I wouldn't mind having a go at this, 
but I'm not sure if this would conflict with some other work.


Best wishes,

Bruno.

Re: Issue 376

[Bruno Harbulot]

Hi Jerôme,

I've been busy with other things since I volunteered last week, so I 
haven't started to work on the getRemoteUser() sub-problem yet, but I 
think I've got a reasonable patch regarding the client certificates.


There are a few problems, though.

1. Even with a clean download of the SVN trunk at the moment (without my 
patch), I can't get it to pass all the tests (in 'verify-tests'). I've 
tried to build the latest code and test it on a Mac (10.5 and Java 5) 
and on a Linux (Java 6), but there's always one test in 
org.restlet.test.RestletTestSuite that fails. I've tried to turn verbose 
on in the junit ant-task, but to be honest, I'm quite confused in all 
the messages that come up. I tend to use jUnit directly from Eclipse 
usually, and in the ant output, the junit messages seem to be lost 
between other logging messages. Is it just me?


2. As part of the test units, is there anything that tests HTTPS (as 
opposed to HTTP)? I couldn't find anything, so I tried to I started to 
work on a com.noelios.restlet.test.SslBaseConnectorsTestCase based on 
com.noelios.restlet.test.BaseConnectorsTestCase (using a dummy 
'localhost' certificate). This raised many more questions, but I'll 
start a new thread. (Some of it has to do with 
http://restlet.tigris.org/issues/show_bug.cgi?id=281 since it's a 
similar topic)


3. There's some good news.
I've written the code to get the clients certificate using Grizzly, 
Jetty (HTTPS and AJP), XdbServlet and Servlet and the Simple connector.
I'm not sure what to do regarding the Stream server. Sorry, I haven't 
really looked into that one and I barely know what it's for. I didn't 
get the impression it was aimed for HTTPS anyway.


Getting the client certificates using Jetty HTTPS and AJP works. I 
haven't tested the Servlet code, but it's the same as the AJP and this 
really should work. It works with the simple connector too.


Grizzly needs a bit more testing: some other problems came up because it 
tends to close the connection abruptly after a timeout (in a similar way 
as it was doing with 1.1M1 and plain HTTP). (An HTTPS test unit would help.)



Best wishes,


Bruno.

Jerome Louvel wrote:

Hi Bruno,

Thanks for proposing to help on this front Bruno. I've reassigned the RFE to
you.

Note that in 1.1 M2, the Guard is automatically adding a Principal instance
to the request attributes upon successful authentication.

Best regards,
Jerome  


-Message d'origine-
De : news [mailto:[EMAIL PROTECTED] De la part de Bruno Harbulot
Envoyé : lundi 3 mars 2008 12:43
À : discuss@restlet.tigris.org
Objet : Issue 376

Hello,

I'm interested in trying to contribute to solve issue 376:
http://restlet.tigris.org/issues/show_bug.cgi?id=376

There are in fact two sub-problems in this issue: (1) exposing 
javax.servlet.request.X509Certificate and (2) defining something that 
would provide the equivalent of 
javax.servlet.http.HttpServletRequest.getRemoteUser().


Is someone already working on it? I wouldn't mind having a go 
at this, 
but I'm not sure if this would conflict with some other work.


Best wishes,

Bruno.

SSL and KeyStores

[Bruno Harbulot]

Hello,


Whilst looking into Issue 376 
, I've been trying 
to implement a test that uses HTTPS, since I can't find one in the 
current test suite. There are a few problems I came across, mainly 
related to Issue 281 .


1. I can't find which properties need to be used for setting the 
keystores and truststores used by the clients. Did I miss something? 
I've had to use -Djavax.net.ssl.keyStore, and similar VM parameters.


2. As Chuck Hinson pointed out as part of Issue 281, keystore and 
truststore should be separate.


3. The implementation that uses the keystore seem to rely on the fact 
that these keystores are always files (at least in the Jetty and Grizzly 
helpers, the Simple helper can handle a null keystorePath). However, 
this is not always true. Some keystores are not file-based: PKCS#11 
tokens and the Apple KeychainStore.


4. There doesn't seem to be a provider parameter for a given keystore. 
This could be useful, if someone would like to use 
KeyStore.getInstance(type,provider), in particular for PKCS#11.



I'd be interested in seeing these issues fixed, and I could have a go at 
it. The way I'm thinking of doing it would be to create more parameters:
serverKeystorePath, serverKeystoreProvider, serverKeystoreType, 
serverKeystorePassword, serverKeyPassword, serverTruststorePath, 
serverTruststoreProvider, serverTruststoreType, 
serverTruststorePassword, serverCertAlgorithm + another set of these for 
client*.


I could see some more complex scenarios where it would be useful to have 
a CallbackHandler to input the password (especially on the client side), 
but... one thing at a time.



Does this make sense? Should I try to address these problems? Any 
suggestions?



Best wishes,

Bruno.

Re: Issue 376

[Bruno Harbulot]

Hi Jerome,

Jerome Louvel wrote:

1. Even with a clean download of the SVN trunk at the moment 
(without my 
patch), I can't get it to pass all the tests (in 
'verify-tests'). I've 
tried to build the latest code and test it on a Mac (10.5 and Java 5) 
and on a Linux (Java 6), but there's always one test in 
org.restlet.test.RestletTestSuite that fails. I've tried to 
turn verbose 
on in the junit ant-task, but to be honest, I'm quite confused in all 
the messages that come up. I tend to use jUnit directly from Eclipse 
usually, and in the ant output, the junit messages seem to be lost 
between other logging messages. Is it just me?


Could you check your "build\temp\test" directory? You will see some log
messages and probably the failing unit test.



I was assuming that it was the same test failing on the Linux box and on 
the Mac, but I was wrong.


- In TEST-org.restlet.test.RestletTestSuite.txt, on a Linux machine 
(Debian), using Sun JDK 1.6.0:


Testcase: testGetList took 0.178 sec
Caused an ERROR
JAXB 2.0 API is being loaded from the bootstrap classloader, but this RI 
(from 
jar:file:/home/bruno/restlet-svn/libraries/javax.xml.bind_2.1/com.sun.jaxb.jar!/com/sun/xml/bind/v2/model/impl/ModelBuilder.class) 
needs 2.1 API. Use the endorsed directory mechanism to place 
jaxb-api.jar in the bootstrap classloader. (See 
http://java.sun.com/j2se/1.5.0/docs/guide/standards/)
java.lang.LinkageError: JAXB 2.0 API is being loaded from the bootstrap 
classloader, but this RI (from 
jar:file:/home/bruno/restlet-svn/libraries/javax.xml.bind_2.1/com.sun.jaxb.jar!/com/sun/xml/bind/v2/model/impl/ModelBuilder.class) 
needs 2.1 API. Use the endorsed directory mechanism to place 
jaxb-api.jar in the bootstrap classloader. (See 
http://java.sun.com/j2se/1.5.0/docs/guide/standards/)
at 
com.sun.xml.bind.v2.model.impl.ModelBuilder.(ModelBuilder.java:136)
at 
com.sun.xml.bind.v2.runtime.JAXBContextImpl.getTypeInfoSet(JAXBContextImpl.java:406)
at 
com.sun.xml.bind.v2.runtime.JAXBContextImpl.(JAXBContextImpl.java:270)
at 
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:103)
at 
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:81)
at 
com.sun.xml.bind.v2.ContextFactory.createContext(ContextFactory.java:152)

at javax.xml.bind.ContextFinder.newInstance(ContextFinder.java:132)
at javax.xml.bind.ContextFinder.find(ContextFinder.java:286)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:372)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:337)
at javax.xml.bind.JAXBContext.newInstance(JAXBContext.java:244)
at 
org.restlet.ext.jaxb.JaxbRepresentation.getContext(JaxbRepresentation.java:307)
at 
org.restlet.ext.jaxb.JaxbRepresentation.access$000(JaxbRepresentation.java:59)
at 
org.restlet.ext.jaxb.JaxbRepresentation$Unmarshaller$1.initialValue(JaxbRepresentation.java:187)
at 
org.restlet.ext.jaxb.JaxbRepresentation$Unmarshaller$1.initialValue(JaxbRepresentation.java:182)

at java.lang.ThreadLocal.setInitialValue(ThreadLocal.java:141)
at java.lang.ThreadLocal.get(ThreadLocal.java:131)
at 
org.restlet.ext.jaxb.JaxbRepresentation$Unmarshaller.getUnmarshaller(JaxbRepresentation.java:210)


at 
org.restlet.ext.jaxb.JaxbRepresentation$Unmarshaller.unmarshal(JaxbRepresentation.java:247)
at 
org.restlet.ext.jaxb.JaxbRepresentation.getObject(JaxbRepresentation.java:532)
at 
org.restlet.test.jaxrs.services.tests.PersonsTest.testGetList(PersonsTest.java:63)


Testcase: testCreate took 0.01 sec
FAILED
expected: but was:
junit.framework.AssertionFailedError: expected: but 
was:
at 
org.restlet.test.jaxrs.services.tests.PersonsTest.testCreate(PersonsTest.java:74)



My guess is that it's picking up JAXB 2.0 which, I think, is in Java 6, 
in rt.jar (on the bootstrap classpath). This link might help: 
https://jaxb.dev.java.net/guide/Migrating_JAXB_2_0_applications_to_JavaSE_6.html#Using_JAXB_2_1_with_JavaSE_6





- In TEST-org.restlet.test.RestletTestSuite.txt, on a Mac (OSX Leopard 
10.5.2, Apple Java 1.5.0_13:


Testcase: testXmlTransformGet took 0.017 sec
FAILED
expected: but was:
junit.framework.AssertionFailedError: expected: but 
was:
at 
org.restlet.test.jaxrs.services.tests.ProviderTest.testXmlTransformGet(ProviderTest.java:276)




- For completeness, I've also tried with Sun Java 1.5.0_14 on the same 
Linux box as above, and I get the same error as with Apple Java 5 on the 
Mac.





2. As part of the test units, is there anything that tests HTTPS (as 
opposed to HTTP)? I couldn't find anything, so I tried to I 
started to 
work on a com.noelios.restlet.test.SslBaseConnectorsTestCase based on 
com.noelios.restlet.test.BaseConnectorsTestCase (using a dummy 
'localhost' certificate). This raised many more questions, but I'll 
start a new thread. (Some of it has to do with 

Re: SSL and KeyStores

[Bruno Harbulot]

Hi Jerome,

Jerome Louvel wrote:

Hi Bruno,

[...]

1. I can't find which properties need to be used for setting the 
keystores and truststores used by the clients. Did I miss something? 
I've had to use -Djavax.net.ssl.keyStore, and similar VM parameters.


No those parameters are indeed missing :-/


OK. I'll try to address this.


2. As Chuck Hinson pointed out as part of Issue 281, keystore and 
truststore should be separate.


Could we add "truststore*" parameters? If they are not present, we could
fall back on current behavior, reusing matching "keystore*" parameters.


Yes, this seems sensible.
So, I think I'll keep keystore* for the server-side (for compatibility), 
add an optional trustore* for the server-side (falling back on the 
server keystore*), add an optional clientKeystore* for the client-side 
(falling back on keystore*), add an optional clientTruststore* (falling 
back on clientKeystore* and truststore*, I haven't really thought 
through which order would be best...)




3. The implementation that uses the keystore seem to rely on the fact 
that these keystores are always files (at least in the Jetty 
and Grizzly 
helpers, the Simple helper can handle a null keystorePath). However, 
this is not always true. Some keystores are not file-based: PKCS#11 
tokens and the Apple KeychainStore.


OK. To be honest, I wasn't aware of this subtelety :)
Would it be hard to provide support for configuring these additional
keystore types?



One way consists of configuring the PKCS#11 provider in the 
java.security properties, which will add a new (named) provider.
With a keystoreProvider property, it should then just be a matter of 
allowing either the InputStream or the provider name to be null, that 
is, changing statements like this:

  KeyStore keyStore = KeyStore.getInstance(getKeystoreType());
  FileInputStream fis = new FileInputStream(getKeystorePath());
  keyStore.load(fis, getKeystorePassword().toCharArray());

into something like this:
  String keystoreProvider = getKeystoreProvider();
  KeyStore keyStore;
  if (keystoreProvider == null)
  keyStore = KeyStore.getInstance(getKeystoreType());
  else
  keyStore = KeyStore.getInstance(getKeystoreType(), 
keystoreProvider);

  FileInputStream fis = null;
  String keystorePath = getKeystorePath();
  if (keystorePath != null)
  fis = new FileInputStream(getKeystorePath());
  keyStore.load(fis, getKeystorePassword().toCharArray());

This would allow both existing keystore, PKCS#11 and Apple KeychainStore 
to be configurable from the same sort kind of properties. I'm not sure 
if all connectors would support this, but this seems reasonably easy to 
implement. In fact, that's more or less what the current Simple 
HttpsServerHelper does.
Is there a guideline in Restlet regarding which coding style is better 
between "( ) ? : " and "if() {} else {}"?



The other way would be to configure the PKCS#11 provider dynamically, 
which would require a few more properties, more re-factoring, more 
special cases to handle...




I'd be interested in seeing these issues fixed, and I could 
have a go at 
it. The way I'm thinking of doing it would be to create more 
parameters:
serverKeystorePath, serverKeystoreProvider, serverKeystoreType, 
serverKeystorePassword, serverKeyPassword, serverTruststorePath, 
serverTruststoreProvider, serverTruststoreType, 
serverTruststorePassword, serverCertAlgorithm + another set 
of these for 
client*.


Sure, that sounds good. Would be keep the current parameters in case we want
to use the same stores for both client and server certificates? 


Yes, indeed. However, I've already run into other related problems for 
trying to use the same keystore for the client and the server.


If a keystore contains both a server and a client set of credentials 
(key+certificate), it seems that the server connectors don't necessarily 
pick up the right one. I made up a TestCA which signed a certificate 
with CN=localhost (for the server) and another with CN=testclient to be 
used by the client and bundled them in the same keystore. The server 
helpers (and what they rely one) were using 'testclient' as a server 
certificate. To be fair my test certificates don't have any usage 
constraints, so maybe the underlying servers would have looked through 
the keystores to find only suitable certificates, but I couldn't really 
find where to specify the name of the alias to be used. There might be a 
wider issue to look into regarding SSL connections: serving several 
certificates if multiple connectors on different IP addresses and 
multiple virtual hosts, certificate with alternate subject names, 
behaviour with TLS, ... This can become complex quite rapidly, and would 
probably take a long time to address (and would also very certainly 
affect Jetty and Grizzly).

In this context, separating client and server keystores seems easier :-)




Best regards,

Bruno.

Re: sketch of a simple authentication protocol

[Bruno Harbulot]

Hello,

Story Henry wrote:

The 5 steps explained:

1. Romeo's User Agent GETs Juliette's public foaf file at 
, that file contains the relation:


  <> rdfs:seeAlso  .

2. Romeo's UserAgent does a GET on the HTTPS URL
  with the extra identification header:

  Agent-Id: http://romeo.name/#romeo


I'd say that steps 1 and 2 are, in effect, very similar to what the WAYF 
(where-are-you-from) steps in Shibboleth [3] do.



  All the https handshake stuff goes on as usual. From this Juliette's 
server extracts the hex id of the SSL key used by Romeo's User Agent.


  [IS THIS POSSIBLE?]


Yes, it could be possible.



[...]

5. Since Juliette's user agent trusts the URL "http://romeo.name/#romeo"; 
- for whatever reason, perhaps her best friend had it in her foaf file - 
and the SSL session was signed by the client with the public key 
identified by hex_id "ABC123AB", she knows that the UserAgent has a 
strong enough trust relation with the person identified by 
, and so she returns the protected information 
over SSL.



Could it really be this simple?


Essentially, what you're designing here is a replacement for X.509 and 
PKI. I'm not sure whether it's a good or bad idea. It could work well. 
However, it's not this simple. The most difficult bit is in "- for 
whatever reason, perhaps her best friend had it in her foaf file -": 
that's essentially what Certificate Authorities (CAs) in PKI are for.
The use of X.509 certificates involves a number of properties, in 
particular extensions in the certificates that define how a certificate 
may be used (some of these extension may be critical), and other pieces 
of information regarding the CAs (including Certificate Revocation 
Lists, etc).
The part of this protocol the Juliette decides whether-or-not to trust 
someone who claims he's romeo would certainly be equivalent to 
implementing all these rules in RDF/Semantic Web (sorry, I don't know 
much about that). I can't think of a reason why this shouldn't be 
possible, but I wouldn't say it's simple.


(As a side-effect, you might also find in practice that what is the 
equivalent of verifying a certificate-chain may involve a large number 
of request to various servers that you trust -- such as that hosting 
"Romeo's public foaf doc".)




In terms of implementation, I haven't tried, but it should be possible 
to achieve what you're after. It would have to be done with caution, 
since it wouldn't fit in the PKI model traditionally expected.


In short, what you need is the ability for Juliette's protected server 
to accept any client certificate, certificate by any CA (or self-signed).


I haven't tried, but this should be possible using Apache HTTPD [4] by 
setting this option:

  SSLVerifyClient optional_no_ca
(That's generally speaking, with or without Restlet if you're using 
Apache HTTPD as your HTTPS server.)


If you want to do it directly within the server provided with Restlet, 
I'm not sure it's possible at the moment. I'm planning to do some work 
on SSL in Restlet, but I've been busy with other things. Basically, what 
this needs is a custom SSLServerSocketFactory that won't verify what 
client-certificate it gets.
I must stress that, if you do that, you'll have to implement some sort 
of verification, perhaps RDF/SPARQL-based, which is going to make all 
the equivalent verifications that the SSLSocket would do. Defining the 
"semantics" (if I may use this word) of who trusts who is no simple 
task. The specifications related to PKI and X.509 can be quite complex; 
although you might not want to stick to them word by word, you'd 
probably end up with similar models.
Practically, if you want to try this in the short term (i.e. with the 
current state of SSL in Restlet), the easiest is probably to use Apache 
with the mod_ssl option above and then AJP in Restlet. (I've started to 
work on a few things to have a more flexible configuration of SSL in 
Restlet, but it's not my main activity so it's getting a bit delayed...)



Getting the public key is relatively simple. The Restlet Request 
attribute "org.restlet.https.clientCertificates" should contain a List 
of X509Certificate [9] (the first one being the client-certificate, the 
following ones representing the chain of certification).
X509Certificate.getPublicKey() on this certificate should give your the 
public-key. Then, you can probably use various methods of Signature [6] 
and X509Certificate.getSignature() to make the verifications.
You'll need a relatively recent version of Restlet (1.1M3) to do this, 
since it's been implemented recently in the AJP [8].


Independently of Restlet, you can achieve the same goal certificates 
using "javax.servlet.request.X509Certificate" in a Servlet request, or 
various HTTP environment variables in PHP/CGI/... [7] (SSL_CLIENT_CERT).



On top of all of this, there also needs to be a mechanism whereby the 
client can ch

Re: sketch of a simple authentication protocol

[Bruno Harbulot]

Story Henry wrote:


On 3 Apr 2008, at 16:15, Adam Rosien wrote:

It may be more appropriate to use the Authorization HTTP header to
pass along Romeo's credentials.  Rob's email using SSL certs only
seems a lot cleaner and doesn't need the client to push anything into
the request.


I need to read up more on HTTPS to understand this, but my initial 
intuition would be that if the key is passed in a header then it could 
be different from the one that is really used. I really need a guarantee 
that I have an identifier for the key used by the client. If I am wrong 
please don't hesitate to let me know :-) for this would indeed be a good 
solution.


Yes, you are right, the client needs to sign something with its private 
key. An HTTPS connection is appropriate for this. Perhaps another 
solution could be inspired by HTTP Digest-Authentication whereby the 
client would sign the response to the challenge.



Best wishes,

Bruno.

SSL configuration

[Bruno Harbulot]

Hello,


I've been looking into enhancing SSL support in Restlet. The main
problem is that the way SSL can be set up is fine for basic cases, but
isn't really sufficiently flexible for more serious uses.
Some of the problems have been described in
http://restlet.tigris.org/issues/show_bug.cgi?id=281


Here is a summary of the problems:

- Client and Server SSL settings ought to be separated. In fact, as far
as I'm aware, there isn't really any way to configure SSL on the client
side (in particular, usage of client certificates).
Although it should be fine to have a single trust store for client and
server, I can think of a few cases where I key stores ought to be
distincts (the client certificate a Restlet application uses as a client
might not be the same as the server certificate it uses).

- Server key-stores should be specific to each virtual host. Indeed, the
server certificate is specific to a particular host-name (except when
using subjectAltNames).

- Certificate Revocation Lists cannot be handled. CRLs are an important
part of PKI. In real-life cases, certificates may have to be revoked
before their expiration date (host machine compromised, users not caring
for their keys properly, users having their keys stolen, etc.). These
things just happen and have to be dealt with.



Here are a few suggestion on how to make changes in Restlet. This would
involve some re-factoring, and I'm not quite sure where and how it's
best to do it.

- On the server side.

It seems that the easiest way is to introduce more flexibility regarding
the creation of an SSLContext, which is what the Grizzly and Simple
HttpsServerHelpers do anyway from the keystores they get.
I've written a (uk.ac.manchester.rcs.sslutils.) SSLContextFactory, which
is an abstract class designed to build and initialise SSLContext from
"sensible" default values that may be configured in the concrete
factories to allow for specific needs. One of its subclasses is a
PKIXSSLContextFactory which makes it possible to load CRLs before
creating and initialising the SSLContext.

In my opinion, having an SSLContextFactory is a rather flexible way to
address this problem. I was able to create another type of factory to
address the SSL requirements of the RDFauth proposal [1][2] quite
quickly (mainly by turning off traditional X.509-related verifications:
use with caution!). (Just to clarify, this was just a test for the
SSLContextFactory, and I haven't integrated any SSLContextFactories in
the Restlet code yet...)

I think that, instead of passing 'keyStorePath', 'sslProtocol',
'securityProvider', etc. to as parameters to the HttpsServerHelper,
passing such an SSLContextFactory would decouple the SSL configuration
from these classes. Another way to do this would be to pass an
initialised SSLContext directly. The latter would probably be a problem
with sub-problem 2 (restarting server sockets), below.


There are a few subsequent problems with this:

 1. The Jetty connector uses SslSelectChannelConnector and
SslSocketConnector, which in effect also build their own SSLContexts
from a set of parameters (keystores, etc.), but do not support a method
such as setSSLContext(...) and are not sufficiently flexible to set up
CRLs. They seem to have the same problem as the current
HttpsServerHelpers in Restlet. Jetty, used without Restlet, supports
some configuration, in that the SslSocketConnector may be sub-classed
and used when configuring Jetty [3]. It's not clear to me how this would
work with the NIO connector.
If I may be optimistic, I suppose it could be envisaged to submit
patches for Jetty to support some "setSSLContext" in these two classes.
I've looked at the code, and it seems feasible. In addition last time I
submitted a (small) patch for Jetty, I was impressed by how quickly it
was handled. I think it would be worth discussing it on the Jetty lists
to see if this could be done.

 2. The problems with CRLs is that, in most cases, they need to be
refreshed periodically. This means that there should also be some sort
of mechanism that restarts the listening sockets every once in a while,
perhaps configurable.

 3. Per virtual-host settings.
  I'm not sure how this can be done. I'm not familiar with how
parameters are passed throughout the code, and I haven't really
experimented with virtual hosts in Restlet.

 4. The packaging of the classes I've written.
  Unfortunately, Java doesn't provide a javax.net.ssl.SSLContextFactory
default interface, which would be handy (Java 6 has an
SSLContext.setDefault(...) method, but this seems to be global, which
wouldn't really help).
  I could package a uk.ac.manchester.rcs.sslutils library containing
these SSLContextFactories and publish it under a Restlet-friendly
licence (let's suppose something like BSD). This library could in turn
be used by Restlet, like Jetty, Grizzly and many others. This might mean
that all the HttpsServerHelpers would depend on it. Somehow, I'm not
sure how this would fit in the current Res

Re: SSL configuration

[Bruno Harbulot]

Hi Jerome,

Jerome Louvel wrote:


- Client and Server SSL settings ought to be separated. In 
fact, as far
as I'm aware, there isn't really any way to configure SSL on 
the client

side (in particular, usage of client certificates).


The idea of allowing the specification of client certificates was discussed
recently (I don't remember which RFE now) and it was supposed to use
additional/optional connector parameters.


I think I had mentioned this topic in a previous message, but I haven't 
filled in an RFE (I haven't checked if there was an existing one either).



- Server key-stores should be specific to each virtual host. 
Indeed, the server certificate is specific to a particular 
host-name (except when using subjectAltNames).


Shouldn't it be specific to a given connector instead? In the end, the
SSLContext info is used to create SSLServerSocket. But, we can create
several instances of the same server connector with different SSL settings,
listening on different IP addresses or ports. 


Then, it is easy to associate a given connector to a given virtual host, by
restricting the vhost to the given IP address or port.


Yes, you are right, this should be specific per connector.
Perhaps I was thinking a bit far ahead, but it might be interesting to 
keep the door open for TLS hostname negotiation as RFC 4366 
 or RFC 2817 
, in which case some 
virtual host settings would be useful. I must admit it's not something I 
have much experience with.

In more realistic terms, connector settings are probably the right choice.


I think it would be worth discussing it on the 

Jetty lists to see if this could be done.


Cool. Do you have a pointer to the Jetty thread/issue?


http://permalink.gmane.org/gmane.comp.java.jetty.general/11379



  2. The problems with CRLs is that, in most cases, they need to be
refreshed periodically. This means that there should also be some sort
of mechanism that restarts the listening sockets every once 
in a while, perhaps configurable.


OK. IMO, this could be handled at a higher level (Restlet Component).


This would probably make sense. You certainly know better.



  3. Per virtual-host settings.
   I'm not sure how this can be done. I'm not familiar with how
parameters are passed throughout the code, and I haven't really
experimented with virtual hosts in Restlet.


IMO, this is in fact a per-connector issue, with the idea that you have
several instances of the same connector (Grizzly connector for example). The
each specific connector can be associated to a given virtual host if needed.


Yes.



   I could package a uk.ac.manchester.rcs.sslutils library containing
these SSLContextFactories and publish it under a Restlet-friendly
licence (let's suppose something like BSD). This library could in turn
be used by Restlet, like Jetty, Grizzly and many others. This 
might mean that all the HttpsServerHelpers would depend on it. 
Somehow, I'm not sure how this would fit in the current Restlet 
packaging model.


One constraint that we have is zero external dependency for the core NRE
JAR, beside the Restlet API. External dependencies are only accepted for
Restlet or NRE extensions.


Yes, this makes sense.



Let me reply to the rest of your email regarding the packaging in your
subsequent email to [EMAIL PROTECTED] as this is more of a technical
topic indeed.


I'll reply on that thread too.



Best wishes,

Bruno.

Re: New Restlet HTTP Connector

[Bruno Harbulot]

Hi Marc,

I've just had a very brief look at the Javadoc. Just a few quick comments:
- se.rupy.http.Query should probably be called Request. Unless I'm 
mistaken that's the class that represents a request and it should 
probably be called as such, this would avoid confusion with the URI 
query part.
- Why would 'header(String)' return "0" when a header isn't found? 
Surely, an present header could have the value "0".

- It seems limited to GET and POST.

Cheers,

Bruno.

Marc Larue wrote:

Hi,

My name is marc and I developed this tiny NIO HTTP server. I'm curious
what you think about adding it to the restlet program.

   http://rupy.googlecode.com

Hope you like it!

Cheers,

/marc

Guards and Principals

[Bruno Harbulot]

Hello,

I've just had a look at the implementation of Guard in 1.1-M3. I was
looking at implementing my own authorisation mechanism, based on the
existing authentication mechanisms (assuming HTTP Basic for now). It 
seems that the Principal-related features have moved into 
ChallengeResponse (I hadn't looked into it very much in 1.1-M2). Is 
there any pointers regarding these features and these changes?


I need to look again at the servlet specification and the JAAS 
documentation, but I think there could be some confusion between Subject 
and Principal in the current implementation. The Servlet security model 
distinguishes User and Role principals. For example, I think that when 
using the JAASRealm in Tomcat, getUserPrincipal returns the first 
Principal of the Subject that is an instance of the configured user 
principal class; however, there could be other role principals in the 
Subject. I'm not sure how this works in practice with a security manager.


In addition, I think it would make sense, when using client certificates 
with SSL, to have the user principal be what's returned by 
getX500Principal() (obtained from the client certificate). However, 
ChallengedResponse is final and the principal seems fixed.


Best wishes,

Bruno.

Re: how can I read the used authentication scheme in a server?

[Bruno Harbulot]

Hi Stephan,

If the request was authenticated using a client certificate, the 
following will be non-null:
  List certificates = 
(List)getRequest().getAttributes().get("org.restlet.https.clientCertificates"); 



I believe this should now work with all types of HTTPS connectors in 
Restlet, included behind AJP or with a Servlet (if not, please let me 
know and/or fill in a bug report).


I assume the JAX-RS specification follows the Servlet specification and 
the ('auth-constraint' configuration element).
However, in principle, client-side SSL authentication and BASIC/DIGEST 
(or even FORM) autentication are orthogonal. You could required both 
client-certificate authentication and either of BASIC, DIGEST or FORM. 
(It's probably not very sensible in practice).
You would also have to configure the server SSL connector to use at 
least "wantClientAuthentication" if not "needClientAuthentication".



I don't really use Restlet with the Servlet connector, so I'm not sure, 
but I don't think it's currently possible to check whether FORM 
authentication has been used (as a matter of fact, I'm not sure whether 
it's possible to check whether BASIC or DIGEST authentication has been 
used when using the Servlet connector). To do so, I would imagine that a 
call to getRequest().getAuthType (the request here being an 
HttpServletRequest) would be required somewhere in 
com.noelios.restlet.ext.servlet.ServletCall, or nearby.




Best wishes,

Bruno.



Stephan Koops wrote:

Hi Bruno and all,

JAX-RS has a method in the API, where the application developer could 
request, which authenticaton scheme was used 
(SecurityContext.getAuthenticationScheme(), if someone is interested)
If the request was authenticated by BASIC, DIGEST, client certificate or 
Servlet form authentication, I have to return a given constant for them.
Check for BASIC and DIGEST is easy, but how can I check, if the request 
was authenticated by SSL client certificate? And how can I check, if it 
was Servlet form authentication?


best regards
   Stephan

Re: read the used authentication scheme from Servlet etc.

[Bruno Harbulot]

Hi,

Jerome Louvel wrote:

The simplest is to modify ServletCall#getRequestHeaders() to automatically
add an "Authorization" HTTP header.
[Double check that this header is not already forwarded by the Servlet
container]


I'm not sure it's a good idea to add an Authorization HTTP header when 
it wasn't present in the client's request.
Some people who were fairly knowledgeable in terms of security got 
bitten at this game: https://spaces.internet2.edu/display/SHIB/SpoofingBug
In short, this authz module was adding a header to propagate information 
further down the chain (from Apache), but didn't reset the header it 
would normally set up when it wouldn't have added it.




Then, you need to recreate the original value of the header, called the raw
credentials.



For that, you have access to the challenge scheme via getAuthType() and to
the user's identifier via getRemoteUser(). For the password, you could try
using an empty or special constant value like "unknown".

Then there is a static
com.noelios.restlet.authentication.AuthenticationUtils#format(ChallengeRespo
nse challenge, Request request, Series httpHeaders) method that
will do the rest of the job for you.

You may have troubles with the "FORM" scheme though. We may need to add
special support for that as a pluggable authentication scheme provided by
the Servlet extension (not really hard).



I thought the problem was only to get the authentication method name 
(FORM/BASIC/DIGEST/CERT) and thus propagate an equivalent to 
HttpServletRequest.getAuthType().


I reckon this is only a problem for FORM, since it's possible to find 
out about the other ones from the original headers that will be passed 
on anyway (BASIC/DIGEST) or from the certificate attribute (SSL client 
auth).


Rather than putting this piece of information into the Form that holds 
the HTTP headers, I'd put it directly as an attribute of the request, 
that is:

 - request.getAttributes().put(...SOME...NAME..., x)
instead of:
 - headerForm.add(new Parameter("Authorization", "FORM");
   request.getAttributes().put(HttpConstants.ATTRIBUTE_HEADERS, headerForm)

I'm not really sure what the best way to do this is, though, in 
particular whether it should be done for all types of request or just 
for this specific type (i.e. only set it from ServletCall and only if 
it's using FORM authentication).
I don't think it's currently possible to set specific attributes of 
HttpRequest from an HttpServerCall (in particular ServletCall), since 
all attributes of HttpRequest seem to be set up by HttpServerConverter 
which calls out to the methods of HttpServerCall (none of which seem to 
be able to set up some attribute specific to them that would be passed 
to the HttpRequest attributes directly).

Re: read the used authentication scheme from Servlet etc.

[Bruno Harbulot]

Hi,


Ooops... Looks like Thunderbird decided it was time to send this before 
it was finished :-)

Bruno Harbulot wrote:

Hi,

Jerome Louvel wrote:
The simplest is to modify ServletCall#getRequestHeaders() to 
automatically

add an "Authorization" HTTP header.
[Double check that this header is not already forwarded by the Servlet
container]


I'm not sure it's a good idea to add an Authorization HTTP header when 
it wasn't present in the client's request.
Some people who were fairly knowledgeable in terms of security got 
bitten at this game: https://spaces.internet2.edu/display/SHIB/SpoofingBug
In short, this authz module was adding a header to propagate information 
further down the chain (from Apache), but didn't reset the header it 
would normally set up when it wouldn't have added it.



Then, you need to recreate the original value of the header, called 
the raw

credentials.


For that, you have access to the challenge scheme via getAuthType() 
and to
the user's identifier via getRemoteUser(). For the password, you could 
try

using an empty or special constant value like "unknown".

Then there is a static
com.noelios.restlet.authentication.AuthenticationUtils#format(ChallengeRespo 

nse challenge, Request request, Series httpHeaders) method 
that

will do the rest of the job for you.

You may have troubles with the "FORM" scheme though. We may need to add
special support for that as a pluggable authentication scheme provided by
the Servlet extension (not really hard).



I thought the problem was only to get the authentication method name 
(FORM/BASIC/DIGEST/CERT) and thus propagate an equivalent to 
HttpServletRequest.getAuthType().


I reckon this is only a problem for FORM, since it's possible to find 
out about the other ones from the original headers that will be passed 
on anyway (BASIC/DIGEST) or from the certificate attribute (SSL client 
auth).


Rather than putting this piece of information into the Form that holds 
the HTTP headers, I'd put it directly as an attribute of the request, 
that is:

 - request.getAttributes().put(...SOME...NAME..., x)
instead of:
 - headerForm.add(new Parameter("Authorization", "FORM");
   request.getAttributes().put(HttpConstants.ATTRIBUTE_HEADERS, headerForm)

I'm not really sure what the best way to do this is, though, in 
particular whether it should be done for all types of request or just 
for this specific type (i.e. only set it from ServletCall and only if 
it's using FORM authentication).
I don't think it's currently possible to set specific attributes of 
HttpRequest from an HttpServerCall (in particular ServletCall), since 
all attributes of HttpRequest seem to be set up by HttpServerConverter 
which calls out to the methods of HttpServerCall (none of which seem to 
be able to set up some attribute specific to them that would be passed 
to the HttpRequest attributes directly).




I know the solution I've describe may not be ideal, but I prefer it to 
adding an made-up authorisation HTTP header. Applications that would use 
it wouldn't be able to tell the difference between "Authorization: " set 
up internally or set up by the client.
Unlike the Shibboleth example, which was making up its own specific 
header (and thus was able to fix its problem by clearing it anyway), the 
Authorization header is actually legitimate in most cases and it could 
be set up by the client, so it would be harder to know when to clear it 
and when not to.



Best wishes,

Bruno.

Re: Guards and Principals

[Bruno Harbulot]

Hi Jerome,

Sorry, forgot to reply to this at the time.

Jerome Louvel wrote:
Hi Bruno, 


I don't remember any specific issue regarding this change. It was done
following some needs regarding the JAX-RS extension.

The ChallengeResponse.getPrincipal() is nothing more than an wrapper around
the ChallengeResponse."identifier" property (user or login names). The value
come from the HTTP authentication headers in general.


OK. So this seems similar to what Tomcat does with its GenericPrincipal 
or Jetty with its HashUserRealm$KnownUser (for example).




We don't have any built-in notion of role in the core Restlet API for now.
There is only a org.restlet.ext.jaxrs.RoleChecker interface in the JAX-RS
extension.


OK. I was wondering if there was something similar to what Jetty and 
Tomcat do (they both have their notions of "realms", although they are 
modelled differently). Using JAAS, they can set the user Principal to 
something JAAS-specific. (The way this can be configured and customised 
differs between Tomcat and Jetty.)

Regarding what I said about Subject, I was myself getting confused...

I think it would be good to allow other types of principals, rather than 
fixing one solely based on the identifier as you mentioned. Not all 
authentication mechanisms rely on user or login names only. For example, 
I've seen a ticket about SPNEGO authentication, in which case I suppose 
it could be good to return a KerberosPrincipal, from which more 
information could be obtained if required.




I agree that having access to the principal of the SSL certificates is
useful, but I don't think it should be part of the ChallengeResponse class.
Maybe it could be part of the org.restlet.data.ClientInfo as this property
will not vary a lot across requests. Maybe the Request class itself or a new
delegate SecurityInfo class if we have a lot of interesting properties to
expose... not sure.


Getting the Principal from the client certificate can already be done by 
calling getX500Principal() on that certificate (position 0 in the list 
obtained via the request attribute). I don't think there's a need to 
implement anything more in ClientInfo. Anyway, I haven't really looked 
into whether Tomcat or Jetty were able to set the user principal to that 
of the certificate in some specific realm configuration.


Having a mechanism similar to Tomcat's and Jetty's Realms in Restlet 
could be interesting, but I don't think I'm going to have time to look 
into this at the moment.



Cheers,

Bruno.



-----Message d'origine-
De : news [mailto:[EMAIL PROTECTED] De la part de Bruno Harbulot
Envoyé : lundi 28 avril 2008 20:28
À : discuss@restlet.tigris.org
Objet : Guards and Principals

Hello,

I've just had a look at the implementation of Guard in 1.1-M3. I was
looking at implementing my own authorisation mechanism, based on the
existing authentication mechanisms (assuming HTTP Basic for now). It 
seems that the Principal-related features have moved into 
ChallengeResponse (I hadn't looked into it very much in 1.1-M2). Is 
there any pointers regarding these features and these changes?


I need to look again at the servlet specification and the JAAS 
documentation, but I think there could be some confusion between Subject 
and Principal in the current implementation. The Servlet security model 
distinguishes User and Role principals. For example, I think that when 
using the JAASRealm in Tomcat, getUserPrincipal returns the first 
Principal of the Subject that is an instance of the configured user 
principal class; however, there could be other role principals in the 
Subject. I'm not sure how this works in practice with a security manager.


In addition, I think it would make sense, when using client certificates 
with SSL, to have the user principal be what's returned by 
getX500Principal() (obtained from the client certificate). However, 
ChallengedResponse is final and the principal seems fixed.


Best wishes,

Bruno.

Re: PUT and entity

[Bruno Harbulot]

Hi Jerome,

Jerome Louvel wrote:

Hi Bruno,

1) Uniform interface

[...]
The bottom line is that HTTP semantics are the reference when defining or 
interpreting the Restlet core API properties or behavior.


HTTP being the de-facto REST protocol reference, it is indeed the right 
choice for Restlet. Having the second layer is certainly useful, but I 
haven't had to use it so far, and I'm hoping not to have to. I think 
this thread on the REST-discuss list is quite useful on this topic:

http://comments.gmane.org/gmane.comp.web.services.rest/7943

The only extension I may have thought could be useful would be something 
like "SEARCH", which would be similar to GET (no side-effects, 
idempotent and proxy-able) but with a body. I'm still against a body in 
GET, since this would break the ability to discover resources. This 
"SEARCH" would in fact just be an implementation detail to solve the 
problem of encoding a large XML-based expression in the URI. I can't 
really think of a good theoretical reason for it (in fact, in theory, I 
quite like the idea of modelling a given search as a resource in its own 
right, however long that URI may be), and if both implementations of 
client and server can handle potentially very long URIs, then there's no 
reason for it. (I haven't tested the limits of Restlet in this matter.)




2) PUT with no entity

I have yet to come across a solid use case that requires this, but I'm not 
fundamentally opposed to allow this if it is really useful or if the current 
behavior is really blocking.


I must admit the cases I was talking about were purely hypothetical, I 
was just surprised by this constraint.



The use case you mention about content negotiation (being able to clear just 
one specific variant) is not allowed by REST (per Roy T. Fielding). I fall into 
the same trap at some point in the past. When you PUT a representation you 
change the *whole* state of your resource. Unless you treat your 
representations as identifiable resources, you can't update or delete a 
specific resource variant. If you think deeply about it that should make sense. 
If you search in the REST-Discuss list you will find related threads.


I'm already convinced!


Regarding status code 204, by interpretation of the spec is that it is expected after a 
POST or PUT method or other, but not after a GET: "The server has fulfilled the 
request but does not need to return an entity-body"
http://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html#sec10.2.5

The list use case can be supported by defining a list item content type, for example an XML representation 
"" instead of "1234".

Anyway, this is my current opinion and I'm open to changing it if necessary. 
This is a good question to ask to the REST-Discuss list or to the HTTP WG 
experts. Maybe there are existing discussions? Any pointer?


Yes, I don't actually feel strongly in favour of allowing PUT requests 
with an empty body. I agree with your arguments. Perhaps the original 
poster on this thread could elaborate on his use-case or raise the 
question on the REST-discuss list.



Bruno.


-Message d'origine-
De : news [mailto:[EMAIL PROTECTED] De la part de Bruno Harbulot
Envoyé : mardi 27 mai 2008 11:17
À : discuss@restlet.tigris.org
Objet : Re: PUT and entity

Hi,

Steve Loughran wrote:

On Tue, May 27, 2008 at 8:13 AM, Stephan Koops <[EMAIL PROTECTED]> wrote:

Hi,

also if the question do not come from me: IMO a generic framework should not
forbid things, that are not explicit forbidden. So, if it is vague, if it is
forbidden or not, then it should be possible to send an request with no
entity (IMO). A possible solution is to allow to switch this forbiddance on
or off.


That's an interesting point. Although Restlet does try and hide you
from the fact that HTTP is underneath, it is still there and ought to
be embraced. At the same time though, theres that XMPP transport, and
it doesnt have to contain the same set of assumptions.


I don't know XMPP in details, but does it have the same uniform 
interface (or at least, is there a one-to-one mapping of XMPP and HTTP 
sets of verbs)? Abstracting away the underlying protocol from the REST 
framework is a good idea, but I guess there's a point where the 
representations have to nail down which transfer protocol can be used, 
or at least what the uniform interface is and how it maps to the 
transfer protocol.
Restlet makes the assumption that this uniform interface consists of 
"get", "accept", "store" and "delete", which maps fairly well to the 
HTTP verbs and this works fine, but I suppose one could have a RESTful 
system where the uniform interface differs slightly from this.




Even so, PUT is taken to mean 'put something there to create a new
resource', so if you dont have a body, what are you creating?

Guards and authentication mechanisms

[Bruno Harbulot]

Hi all,


Following the discussion on the authentication scheme a few days ago, 
I've been looking at

 - "Access to connector authentication"
  http://restlet.tigris.org/issues/show_bug.cgi?id=503
 - "Add notion of realm"
  http://restlet.tigris.org/issues/show_bug.cgi?id=504
 - "Add support for Guards based password files encrypted by htpasswd"
  http://restlet.tigris.org/issues/show_bug.cgi?id=485

I've also been looking a bit more generally at Guards, and this raised a 
few questions/observations/suggestions, which I suppose could be part of 
this discussion.


I get the impression that a few things in the Guard API are there for 
historical reasons (I suppose the first implementation of Guard only 
supported HTTP BASIC).


I'm trying to think of a Guard class that would be sufficiently abstract 
to model various types of authentication, not only HTTP BASIC/DIGEST, 
but also SSL client-certificates, SPNEGO Kerberos, Shibboleth and 
perhaps forms.
I'm just not sure that the notions of Realm (i.e. BASIC/DIGEST realms), 
Secrets (known Map), SecretResolver, DomainURI and Nonce all belong 
there. What I mean is that perhaps there should be subclasses of Guard 
per authentication mechanism.


In contrast, the solution suggested to issue 485 (htpasswd) is a 
subclass, and perhaps there should be the notion of a 
authentication-provider instead. Similarly, I'm not familiar with the 
OAuth Guard, but I get the impression it doesn't make much use of Realm, 
Secrets, etc.


For example, in Apache Httpd, it's possible to configure mod_auth_basic 
[1][2] with several authentication providers used in to authenticate the 
user, for example file (htpasswd) or ldap. There's also a mechanism that 
In one of the machines I've set up, I've used something where it's 
possible to fake the SSL client certificate as a username in the file. 
(It's thus possible to have cert-based authentication and LDAP 
username/password as a fallback mechanism.)
There would need to be at least two categories of password-based 
providers: the ones from which the secret can be extracted (required for 
DIGEST) and the others.


It's just a vague suggestion, but there could be something like this:

* AuthProvider (abstract?)
* SslAuthProvider extends AuthProvider
 (checking the subject DN or perhaps other things)
* PasswordAuthProvider extends AuthProvider
 (of which the secret itself can't be obtained)
- checkPassword(String username, char[] password): boolean
* ExtractablePasswordAuthProvider extends PasswordAuthProvider
 (one that can reveal the secret as well)
- getPassword(String username): char[]

There could be more concrete implementations:
* PasswordMapAuthProvider extends ExtractablePasswordAuthProvider
 (more or less the same as the current secret map).
* LdapAuthProvider extends PasswordAuthProvider
 (which checks the password against an existing LDAP server)
* HtpasswdAuthProvider extends PasswordAuthProvider
 (which checks the password from a file as described in issue 485)
* JdbcAuthProvider extends ExtractablePasswordAuthProvider
 (which would get the password from a database)

Then, perhaps a (more) abstract Guard and then classes like these:
* HttpBasicGuard extends Guard
 (constructed or somehow provided with a PasswordAuthProvider, it 
doesn't actually need to check against a known secret)

* HttpDigestGuard extends Guard
 (constructed or somehow provider with an 
ExtractablePasswordAuthProvider, since it would need to know the password)


These Guards could also take a list of providers rather than a single 
one, perhaps to have a fallback solution.
All this being said, this wouldn't cover the case I was mentioning 
earlier of SSL-cert falling back to HTTP BASIC/LDAP, so I'd need to 
think a bit more about this.


In addition, perhaps the AuthProviders could be used in relation to the 
Realms, etc. They could provide a suitable instance of Principal (e.g. 
LdapPrincipal, KerberosPrincipal, ... when JAAS is used). There's 
clearly some overlap between this notion of authentication-providers 
(similar to Apache Httpd) and the notion of realms (as in Tomcat or Jetty).


This would clearly require a bit more thoughts, but does the general 
idea seem sensible?


Best wishes,

Bruno.


[1] http://httpd.apache.org/docs/2.2/mod/mod_auth_basic.html
[2] http://httpd.apache.org/docs/2.2/mod/mod_authnz_ldap.html

Re: Guards and authentication mechanisms

[Bruno Harbulot]

Hi Rhett,

Yes, you are right. The Guard class should allow for multiple challenge 
schemes (although it would be more realistic to try them one at a time). 
There could be a list of challenge scheme instances in the Guard. Each 
of these challenge scheme instances could be associated with an 
authentication provider (or list thereof) and an authorisation provider, 
if appropriate. (This would be substantially different to the current 
ChallengeScheme, though).


Best wishes,

Bruno.

Rhett Sutphin wrote:

Hi Bruno,

This general idea is good.  I have one small objection, though:  HTTP 
allows multiple challenges per 401 response.  This means you might want 
to have a guard with parallel authentication checks.  For this reason, I 
don't think that subclassing Guard per authentication scheme (basic, 
digest, etc.) is appropriate.


Rhett

On May 28, 2008, at 4:35 PM, Bruno Harbulot wrote:


Hi all,


Following the discussion on the authentication scheme a few days ago, 
I've been looking at

- "Access to connector authentication"
 http://restlet.tigris.org/issues/show_bug.cgi?id=503
- "Add notion of realm"
 http://restlet.tigris.org/issues/show_bug.cgi?id=504
- "Add support for Guards based password files encrypted by htpasswd"
 http://restlet.tigris.org/issues/show_bug.cgi?id=485

I've also been looking a bit more generally at Guards, and this raised 
a few questions/observations/suggestions, which I suppose could be 
part of this discussion.


I get the impression that a few things in the Guard API are there for 
historical reasons (I suppose the first implementation of Guard only 
supported HTTP BASIC).


I'm trying to think of a Guard class that would be sufficiently 
abstract to model various types of authentication, not only HTTP 
BASIC/DIGEST, but also SSL client-certificates, SPNEGO Kerberos, 
Shibboleth and perhaps forms.
I'm just not sure that the notions of Realm (i.e. BASIC/DIGEST 
realms), Secrets (known Map), SecretResolver, DomainURI and Nonce all 
belong there. What I mean is that perhaps there should be subclasses 
of Guard per authentication mechanism.


In contrast, the solution suggested to issue 485 (htpasswd) is a 
subclass, and perhaps there should be the notion of a 
authentication-provider instead. Similarly, I'm not familiar with the 
OAuth Guard, but I get the impression it doesn't make much use of 
Realm, Secrets, etc.


For example, in Apache Httpd, it's possible to configure 
mod_auth_basic [1][2] with several authentication providers used in to 
authenticate the user, for example file (htpasswd) or ldap. There's 
also a mechanism that In one of the machines I've set up, I've used 
something where it's possible to fake the SSL client certificate as a 
username in the file. (It's thus possible to have cert-based 
authentication and LDAP username/password as a fallback mechanism.)
There would need to be at least two categories of password-based 
providers: the ones from which the secret can be extracted (required 
for DIGEST) and the others.


It's just a vague suggestion, but there could be something like this:

* AuthProvider (abstract?)
* SslAuthProvider extends AuthProvider
(checking the subject DN or perhaps other things)
* PasswordAuthProvider extends AuthProvider
(of which the secret itself can't be obtained)
   - checkPassword(String username, char[] password): boolean
* ExtractablePasswordAuthProvider extends PasswordAuthProvider
(one that can reveal the secret as well)
   - getPassword(String username): char[]

There could be more concrete implementations:
* PasswordMapAuthProvider extends ExtractablePasswordAuthProvider
(more or less the same as the current secret map).
* LdapAuthProvider extends PasswordAuthProvider
(which checks the password against an existing LDAP server)
* HtpasswdAuthProvider extends PasswordAuthProvider
(which checks the password from a file as described in issue 485)
* JdbcAuthProvider extends ExtractablePasswordAuthProvider
(which would get the password from a database)

Then, perhaps a (more) abstract Guard and then classes like these:
* HttpBasicGuard extends Guard
(constructed or somehow provided with a PasswordAuthProvider, it 
doesn't actually need to check against a known secret)

* HttpDigestGuard extends Guard
(constructed or somehow provider with an 
ExtractablePasswordAuthProvider, since it would need to know the 
password)


These Guards could also take a list of providers rather than a single 
one, perhaps to have a fallback solution.
All this being said, this wouldn't cover the case I was mentioning 
earlier of SSL-cert falling back to HTTP BASIC/LDAP, so I'd need to 
think a bit more about this.


In addition, perhaps the AuthProviders could be used in relation to 
the Realms, etc. They could provide a suitable instance of Principal 
(e.g. LdapPrincipal, KerberosPrincipal, ... when JAAS is used). 
There

Re: Guards and authentication mechanisms

[Bruno Harbulot]

Hi all,

Jerome Louvel wrote:

Hi all,

Thanks Bruno for the nice synthesis, that definitely helps moving forward. I
have entered a new RFE to consolidate your comments and other ones from
Stephan:

"Refactor authentication and authorization"
http://restlet.tigris.org/issues/show_bug.cgi?id=505 


Stephan, I agree that this will take some time to properly refactor and take
all aspects into account. I've listed 13 (!) related issues that I added in
the "blocks" field. 


I don't think it would be wise to rush changes into 1.1 so I have set the
milestone to 1.2 M1. 


Yes, I agree, no rush. Those of us who actually need such Guards in 
practice can more or less implement them in 1.1 as plain Filters or 
subclasses of Guard.
I'll try to think of more esoteric authnz mechanisms (for example 
Shibboleth, which we use in parts of the project I work on).
I've actually just had a rather successful go at implementing a SPNEGO 
Filter using the JAAS/GSS mechanism of Java 6, based on Kerberos. It's 
just a proof of concept and the code isn't very clean (I've cut a few 
corners when implementing my own ChallengeScheme and 
AuthenticationHelper), but it seems to work. (At least to test, being 
able to write the 'WWW-Authenticate' headers directly or at having 
something a bit simpler than AuthenticationHelper.formatParameters(...) 
would have made it a bit easier.)
I can't guarantee if and how much time I can spend on this, but I'll try 
to give more details sometime soon.



Best wishes,

Bruno.

Re: Guards and authentication mechanisms

[Bruno Harbulot]

Hi Jerome,

One think that could help in the short term for experimenting would be 
to be able to override the standard HTTP headers. I'm thinking of 
HttpConstants.HEADER_WWW_AUTHENTICATE to be specific, which 
HttpConverter.addAdditionalHeaders(...) makes impossible to override. 
It's therefore a bit more tricky to try out responding with multiple 
WWW-Authenticate headers (Rhett was mentioning this issue in this thread 
and in ).


Could there be some sort of flag to allow headers to be overridden?

Perhaps removing 
"param.getName().equalsIgnoreCase(HttpConstants.HEADER_WWW_AUTHENTICATE)" 
in the list of tests might be the easiest.
I suppose the only danger would be a maliciously crafted Application 
served within a container than doesn't require authentication to get the 
a password via HTTP basic for example. (I'm not sure how many people 
would run applications they don't trust within a Restlet container at 
the moment; this is probably unlikely.)
If this was a problem, perhaps some sort of connector property along the 
lines of ALLOW_OVERRIDE_HTTP_HEADERS, defaulting to false, would work I 
guess.


Best wishes,

Bruno.


Jerome Louvel wrote:

Hi Bruno,

That sounds good, that for continuing the thinking. For SPNEGO, feel free to
post comments on the RFE:

"Support SPNEGO authentication"
http://restlet.tigris.org/issues/show_bug.cgi?id=444 


Best regards,
Jerome

Re: from the org.restlet.data.Request, get the HttpServletRequest

[Bruno Harbulot]

Hi,

Jennifer J. Chen wrote:

Hi All,

I am a newbie to restlets.  Currently I have a restlet client 
communicating with the restlet engine on another machine.  On the server 
side the code is basically an Application extending 
**org.restlet.Application **which looks at the URI and forward it to the 
correct resource.


I will like to integrate the server side code with an existing 
application for authentication and in order to do this, I need the 
original HttpServletRequest and HttpServletResponse.  The authentication 
will be performed in the resource class.  Is there anyway to extract 
this from the reslet request?


We were having a discussion on this list a few days ago about Guards, 
authentication and potential changes in this domain.
Could you give more details on the authentication mechanism you're 
using? Is it Servlet-specific, some custom mechanism for your particular 
application? Some sort of specification would be helpful if it exists.


Best wishes,

Bruno.

Re: Guards and authentication mechanisms

[Bruno Harbulot]

Hi Jerome,

Jerome Louvel wrote:
 
Hi Bruno,


I'm not sure we want to add such a feature in an official build.


Fair enough.


Also, if you can come up with a patch that would add a
"getChallengeRequests():List" method on Response and
deprecate the current "challengeRequest" property, that could go in 1.1 RC. 


Of course, that would require doing the proper formatting and parsing
to/from the "WWW-Authenticate" header.


I've just submitted a patch to 
http://restlet.tigris.org/issues/show_bug.cgi?id=457


Basically, setChallengeRequest is deprecated (and uses the first entry 
in the list) and replaced with addChallengeRequest and 
setChallengeRequests; getChallengeRequest is also deprecated and 
replaced with getChallengeRequests.


I think the only class that uses getChallengeRequest is Dispatcher in 
com.noelios.restlet.ext.shell.controller.



I've just tried it with my toy SPNEGO Filter, and it works. At least 
Firefox and Safari support HTTP Basic authentication if a Kerberos 
ticket wasn't available.



Best wishes,

Bruno.

Re: Guards and authentication mechanisms

[Bruno Harbulot]

Hi Jerome,

Jerome Louvel wrote:

Hi Bruno,
 
Thanks for the patch! A slightly modified version has been checked in 
SVN trunk:

 - better concurrency support
 - no more addChallengeRequest() method
 - use getChallengeRequests().add(..) instead)
 
Let me know if I broke anything :-)


Thanks, it seems to work (at least, the code I'm using doesn't seem to 
be broken :-) ).


I must admit I still don't get the full picture of the way concurrency 
is handled within Restlet. I wasn't quite sure what to do. 
CopyOnWriteArrayList is definitely a good idea.


What I'm less clear about is the benefits of the double-check locking 
(DLC) pattern. I think the intent behind this pattern was to improve 
performance, but was in fact broken until the Java 5 memory model (and 
the use of 'volatile', which is done here).


I don't think 'volatile' and the DCL are necessary, they could be 
replaced with a simple lock. I doubt they really improve performance, 
since 'volatile' effectively has some synchronisation overhead anyway. 
The DCL could be removed to have a simple "synchronized(this) { if 
(field==null) ... }". 'volatile' could be removed as well, if the other 
accessors were also synchronised (probably better).



Best wishes,

Bruno.

Re: from the org.restlet.data.Request, get the HttpServletRequest

[Bruno Harbulot]

Hi Jennifer,

Jennifer J. Chen wrote:


Bruno,

Thank you for your response.

Currently I have two purchased systems communicating with each other 
through custom software using a servlet and xml response.  What I will 
like to do is to turn this into web service client and service 
architecture.  I did not write the software for the receiving system, 
but do use provided APIs to validate the user.  In order to use the APIs 
I need the original HttpServletRequest.


I am not sure how restlets can be useful if it cannot integrate with 
legacy or existing systems.



If you're given some library which has an API of the form 
"authenticate(HttpServletRequest servletRequest)", then I think what Rob 
suggested in reply to your message is probably the cleanest solution: 
creating a "fake" HttpServletRequest, populated with the relevant 
information from the Restlet Request.
Perhaps there could be some utility class to do this conversion. Feel 
free to contribute the code if you implement it...



Best wishes,

Bruno.

Re: Guards and authentication mechanisms

[Bruno Harbulot]

Hello,

Tim Peierls wrote:
On Wed, Jun 4, 2008 at 9:00 AM, Bruno Harbulot 
<[EMAIL PROTECTED] 
<mailto:[EMAIL PROTECTED]>> wrote:




Josh Bloch has a nice presentation of the tradeoffs in Effective Java, 
2nd edition, Item 71. I'll try to summarize briefly.


First, and most important, don't use lazy initialization unless you need 
to.


The main reasons you might need to are: performance (when initializing 
an instance is very expensive and the need for initialization is 
relatively rare among instances) and to break initialization circularities.

[...]
This last one is somewhat delicate because it involves reasoning about 
the memory effects of volatile reads and writes -- don't deviate from 
the pattern above. But it can be significantly faster than the 
synchronized accessor on modern multiprocessor architectures, and it is 
highly unlikely to be worse.


Thank you for all these details. I was a bit confused, because in "Java 
Concurrency in Practice", you don't seem very fond of the double-check 
idiom (even when volatile is used).


By any chance, do you have any benchmarking results that would indicate 
when using lazy initialization and double-check idioms performs better?
I'm not sure whether this particular patch 
(Response.getChallengeRequests [1], not the one I had submitted which 
didn't have synchronization at all... very bad, sorry) benefits much 
from lazy initialization or could have used a non-volatile 
challengeRequests field GuardedBy("this").


(I'd also be interested in the benchmarking applications so that we can 
try them on our machines, if possible.)


Best wishes,

Bruno.

[1] 
http://restlet.tigris.org/source/browse/restlet/trunk/modules/org.restlet/src/org/restlet/data/Response.java?rev=3256&r1=3144&r2=3256

Re: from the org.restlet.data.Request, get the HttpServletRequest

[Bruno Harbulot]

Hi Rob,

Rob Heittman wrote:


I think we need an RFE on that utility, and it should be a standard part 
of the Servlet extension. 


Very good points. Just a small comment: isn't the Servlet extension what 
allows Restlets to be "wrapped" into a Servlet environment (I don't 
actually use it)? I think perhaps this utility should be in a separate 
extension, since it would make it possible to use Servlet-based code 
from Restlet, but might not require Restlet to use the Servlet connector.


Being able to reuse code that was written for Servlets is definitely a 
good idea. This goes along the lines of a comment that I made in 
http://restlet.tigris.org/issues/show_bug.cgi?id=376 about SSL client 
certificates being converted into as List rather than kept in an array 
(what Servlets do). It doesn't really matter in this particular instance 
since it's quite easy to convert the List back into an array, but 
staying close to Servlets when possible seems like a good thing.


Best wishes,

Bruno.

Re: Guards and authentication mechanisms

[Bruno Harbulot]

Hi,

Perhaps this can help, I've made a (long) list of authentication 
mechanisms (about as many as I could find and I've tried most):

http://blog.distributedmatter.net/post/2008/06/09/HTTP-authentication-mechanisms-and-how-they-could-work-in-Restlet

I was looking into which authentication information could be obtained 
from the server (in the sense of what can then be used for making an 
authorisation decision).


Best wishes,

Bruno.


Jerome Louvel wrote:

Hi Bruno,

That sounds good, that for continuing the thinking. For SPNEGO, feel free to
post comments on the RFE:

"Support SPNEGO authentication"
http://restlet.tigris.org/issues/show_bug.cgi?id=444 


Best regards,
Jerome


-Message d'origine-
De : news [mailto:[EMAIL PROTECTED] De la part de Bruno Harbulot
Envoyé : dimanche 1 juin 2008 23:50
À : discuss@restlet.tigris.org
Objet : Re: Guards and authentication mechanisms

Hi all,

Jerome Louvel wrote:

Hi all,

Thanks Bruno for the nice synthesis, that definitely helps moving forward.

I

have entered a new RFE to consolidate your comments and other ones from
Stephan:

"Refactor authentication and authorization"
http://restlet.tigris.org/issues/show_bug.cgi?id=505 


Stephan, I agree that this will take some time to properly refactor and

take

all aspects into account. I've listed 13 (!) related issues that I added

in
the "blocks" field. 


I don't think it would be wise to rush changes into 1.1 so I have set the
milestone to 1.2 M1. 


Yes, I agree, no rush. Those of us who actually need such Guards in 
practice can more or less implement them in 1.1 as plain Filters or 
subclasses of Guard.
I'll try to think of more esoteric authnz mechanisms (for example 
Shibboleth, which we use in parts of the project I work on).
I've actually just had a rather successful go at implementing a SPNEGO 
Filter using the JAAS/GSS mechanism of Java 6, based on Kerberos. It's 
just a proof of concept and the code isn't very clean (I've cut a few 
corners when implementing my own ChallengeScheme and 
AuthenticationHelper), but it seems to work. (At least to test, being 
able to write the 'WWW-Authenticate' headers directly or at having 
something a bit simpler than AuthenticationHelper.formatParameters(...) 
would have made it a bit easier.)
I can't guarantee if and how much time I can spend on this, but I'll try 
to give more details sometime soon.



Best wishes,

Bruno.

Re: Safari content-negotiation...

[Bruno Harbulot]

Hello,

I'm not sure if it the answer you're looking for, but to solve this 
problem, rather than relying on the user-agent header, I declare the 
variants in the following order:

getVariants().add(new Variant(MediaType.APPLICATION_XHTML_XML));
getVariants().add(new Variant(MediaType.APPLICATION_XML));

Thus, at least Firefox and Safari get the XHTML first. To get the 
non-browser clients to get the XML, I simply use an 'Accept: 
application/xml' header in their requests, which I find easier to set up 
than tweaking with the browser configuration (not all users would be 
willing to do this).


The other thing you could do, which works at least with IE and Firefox 
would be to provide XML only and embed an XSLT stylesheet processing 
instruction to make the transformation within the browser. (We've done 
this sort of thing with WSRF [1].) I have used it with Restlet directly 
and it works.


Best wishes,

Bruno.


[1] http://www.ibm.com/developerworks/edu/gr-dw-gr-ajaxwsrflite.html

Ralf Bommersbach wrote:

Hello,

some time ago I posted a question regarding Firefox content-negotiation 
preferences (problem: prefers XML over HTML), see here:

http://www.mail-archive.com/discuss@restlet.tigris.org/msg04958.html

as you can see in the thread I was able to solve the problem (with the 
help of the list, thanks very much) by using the Tunnelservice and the 
agent.properties / accept.properties files.


I face now the same problem with Safari 3.1 for Windows. It also - per 
default - show the XML (only the text-content of the nodes) if there are 
multiple available representations and no explicit mimeType is requested 
(e.g. per file-extension).


The difficulty I have in correcting this behavior is that the User-Agent 
template provided in the agent.properties seems to be the one for 
Safari-2 on Mac and the new one for Safari-3 on Windows is slightly 
different, as you can see here:

http://www.mail-archive.com/discuss@restlet.tigris.org/msg04958.html

I have been trying to modify the user-agent template in the file so that 
it fits the Safari3, but so far I have no luck: I must be doing 
something wrong and I fear I have not enough in-depth understanding of 
how exactly the tunnelservice/user-agent mechanism works to get this 
right...


and ideas/help would be appreciated, thanks!

Best regards
Ralf Bommersbach

Re: SSL + Virtual Hosts and Issue #489?

[Bruno Harbulot]

Hi Alex,

I'll start with the short answer: the workaround you're using, which 
consists of putting a single pair of key/certificate (with associated 
chain of certificates perhaps) per keystore, seems to be the most 
practical solution.


That's what I do, personally. I find it easier to manage my keys and 
certificates using PKCS#12 (.p12) files, storing a single private key 
per file. PKCS#12 files are a type of keystore that's recognised by 
Java, using keyStoreType="PKCS12". This is perhaps because that's how I 
get my certificates from our certification authority: that's the format 
the browser (Firefox at least) uses to export key/certificates (this 
saves me some import/export operations to JKS using keytool). The other 
type of keystore I tend to use is the Apple KeychainStore (OSX only), 
but it has a bug whereby only one private key can be used anyway.



Any particular reason why you would need two pairs of private 
key/certificates in the same keystore in practice? If you want to use 
two certificates, you're going to have to configure two connectors 
anyway, so I would imagine having two keystore files is not necessarily 
a major problem.




More details... I don't think this problem is specific to Restlet. What 
I've tried to do with jSSLutils and the SSL extension to Restlet is to 
make it a bit easier to configure the SSLContext, preferably 
independently of the underlying type of connector.
Choosing the alias can be done by configuring the X509KeyManager, I've 
tried to make this a bit more flexible with jSSLutils by providing an 
X509KeyManagerWrapper (since version 0.3). This being said, it's not 
something I've tried extensively, but it should be possible to write a 
relatively simple wrapper that helps you pick a given alias based on the 
hostname of the socket.



Currently, although the classes related to SSLContext factories are in 
the Restlet tree, they're not used. What's missing is:


1. We'd need to agree on a parameter name to pass an SslContextFactory 
instance, in a similar way to the way the current SSL parameters are 
passed; this shouldn't be a big problem.


2. The underlying Jetty connectors (of Jetty) used by the Jetty 
connector (of Restlet) don't support "setSslContext". I've submitted a 
patch to Jetty for this, but I don't think it's been integrated yet. I 
should follow this up (I think they'd be keen on seeing a unit test), 
but I haven't had time to do so recently. I haven't really pushed for 
this, since I doubt this feature will be in Jetty 6.1.x anyway, only in 
7.x, which most certainly won't be used in Restlet 1.1.
What we could do meanwhile would be to have a custom implementation of a 
Jetty connector (org.mortbay.jetty.AbstractConnector) that would support 
setSslContext in the Restlet connector.
The other connectors (Grizzly and Simple) can use "setSslContext" or 
equivalent.



Best wishes,

Bruno.


Alex Milowski wrote:

I ran into a problem just yesterday with wildcard SSL certificates.  I
had a new keystore with
two wildcards certificates in it and, by default, restlet seemed to
pick the wrong one.  When I
deleted the wrong wildcard from the keystore, everything worked fine.

I'll confess that the interaction between keystores, SSL, and Restlet
is something I
just don't quite understand.

Now, looking at issue #489, I see that there are some changes coming that
should help me.  Can some detail how I'll be able to use this new SSL
context factory
to handle associating certifcates (or aliases in a keystore) with a
virtual host?

--Alex Milowski

Re: SSL + Virtual Hosts and Issue #489?

[Bruno Harbulot]

Hi Alex,

Alex Milowski wrote:

On Wed, Jul 2, 2008 at 7:45 AM, Bruno Harbulot
<[EMAIL PROTECTED]> wrote:

Hi Alex,




Any particular reason why you would need two pairs of private
key/certificates in the same keystore in practice? If you want to use two
certificates, you're going to have to configure two connectors anyway, so I
would imagine having two keystore files is not necessarily a major problem.


No particular reason.  In fact, the lesson I learned here was not to
keep them in the
same keystore.


[...] This being said, it's not
something I've tried extensively, but it should be possible to write a
relatively simple wrapper that helps you pick a given alias based on the
hostname of the socket.


OK.  Eventually I'm going to need this... :)


I'm not sure you would actually need this if you can keep a single 
identity (private key + certificate + perhaps chain of CA certificates) 
per keystore. However, I too would be interested in seeing this, 
especially when Apple fix their KeychainStore implementation (I'm not 
sure when this may be).





Why can't we set properties on the VirtualHost instance as to what alias and
what keystore should be used for SSL transport?


There can only be one certificate per IP address (unless using a 
different port), thus one certificate per connector. (An exception to 
this would be to use something like what GnuTLS does [1], but I've never 
seen it used in practice. I'm not sure at all how browsers and other 
clients support that sort of negotiation.)


Assuming you'd want to do this on a Connector rather than on a 
VirtualHost, this would still have to be implemented in the KeyManager 
(and thus in the SSLContext). I'll try to make things progress on the 
Jetty side and/or find another solution soon. I'm not sure when the 
Restlet 1.1 RC1 is due for, but I haven't had much spare time for this 
recently.


Cheers,

Bruno.

[1] 
http://www.g-loaded.eu/2007/08/10/ssl-enabled-name-based-apache-virtual-hosts-with-mod_gnutls/

Re: XForm integration with the RestLet framework possible?

[Bruno Harbulot]

Hi,

In our system, we use content-type negotiation to serve our own 
content-type (XML-based) to the client API and XHTML to web-browsers. An 
XSLT transform to produce some XHTML with XForms and incorporate the 
data into the XForm instance. The browser-based interface was originally 
intended to be used for debugging the service, thus we used the Mozilla 
XForms plugin in Firefox 2, which was fine for a handful of 
developers/testers. The XML data mostly comes from a relational database 
(Oracle/PostgreSQL) via Hibernate (unfortunately, Hibernate doesn't 
handle Oracle's XmlType, so we resort to a few tricks).
Since Firefox 3, this plugin not available for FF3, so I've tried 
FormFaces(.com), which essentially transforms the XForms into HTML forms 
with JavaScript. It works with more browsers (Firefox 2, Safari 3, IE 7) 
but not all (IE 8b2, Firefox 3, Opera).
I've had a quick look at Shiba last week, but haven't had time to 
investigate it further; it seems it could work well, but I was wondering 
how its notion of session would work out. I've only had a briefer look 
at Oberon, but I'd be keen on seeing how it could work with Restlet.


Best wishes,

Bruno.


Rémi Dewitte wrote:
I don't know very well about OPS. I just like to let you know that I 
have been able to integrate successfully (so far) Saxon and Restlet. I 
might publish it as an extension.
Basically, Restlet does the handling of requests delegating processing 
to xqueries. All the application logic and presentation logic is written 
with xquery.


I don't really know what kind of framework you would like to use to 
"connect" to your datasources but I think that Restlet has no builtin 
for these concerns.


Hope it helps,
Rémi

On Tue, Jul 8, 2008 at 1:30 AM, ilango <[EMAIL PROTECTED] 
> wrote:


Hi
Could you elaborate more on this Resource subclass?

thanks
ilango




--- On *Mon, 7/7/08, Avi Flax /<[EMAIL PROTECTED]
>/* wrote:

From: Avi Flax <[EMAIL PROTECTED] >
Subject: Re: XForm integration with the RestLet framework possible?
To: discuss@restlet.tigris.org 
Date: Monday, July 7, 2008, 3:39 PM


On Fri, Jul 4, 2008 at 3:41 PM, ilango <[EMAIL PROTECTED]
> wrote:

I have an XForm built on the OPS XForms processor. Rather
than use the OPS pipelines for connecting my XForms to
datasources I would like to use the Restlet Framework to
connect my XForm fields to datasources like MySQL, a Web
Service, XML databases like eXist, etc.

I would like to get XML data into my XForm, regardless of
the type of datasource.


I'm not feeling this. Not sure this is something that the
framework, or even an extension, should handle. Could be a
slippery slope towards the framework trying to be everything for
everyone. Why not just write the glue yourself in a Resource
subclass?
 
-- 
Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com

Re: SSL + Virtual Hosts and Issue #489?

[Bruno Harbulot]

Hi Alex,

Alex Milowski wrote:

On Thu, Jul 3, 2008 at 2:36 PM, Bruno Harbulot
<[EMAIL PROTECTED]> wrote:

There can only be one certificate per IP address (unless using a different
port), thus one certificate per connector. (An exception to this would be to
use something like what GnuTLS does [1], but I've never seen it used in
practice. I'm not sure at all how browsers and other clients support that
sort of negotiation.)

Assuming you'd want to do this on a Connector rather than on a VirtualHost,
this would still have to be implemented in the KeyManager (and thus in the
SSLContext). I'll try to make things progress on the Jetty side and/or find
another solution soon. I'm not sure when the Restlet 1.1 RC1 is due for, but
I haven't had much spare time for this recently.


What I'd like to be able to do is have a certificate (i.e. alias in a
keystore) be
associated with a Virtual host so that if I have two virtual hosts on one server
I can associate the different SSL certificates with each host's connection.

Now, I can work around the IP address limitations by using additional addresses
on the server.  Is this a Restlet limitation, a Jetty limitation, or a Java
SSL implemenation limitation?


In the latest revision in the subversion tree, it's now possible to set
an an SSLContext, via the sslContextFactory context parameter.
Thus, it's also possible to customise the KeyManagers (whether-or-not
using jSSLutils), which should make it possible to achieve what you're
after.
Let's assume that host1.example.org is 10.0.0.1 and host2.example.com is
10.0.0.2 and that you have added a couple of servers.


There are two possible situations:

1. We assume there's going to be a single SSLContext common to all 
servers of the component created via an SslContextFactory (it's set up 
in the Context of the Component).


In theory, it should be possible to set up the SSLContext to use a 
custom X509KeyManager [1] that implements chooseServerAlias(String 
keyType, Principal issuers, Socket socket) to choose the appropriate 
alias depending on the listening socket that is used.
Unfortunately, I've tried, and the "socket" passed to that method is 
temporary socket that has almost the same characteristics as the actual 
one, but not all, especially not the local address, which is what we 
would need. I've just talked about it with the OpenJDK security team 
[2], but I wouldn't expect a fix in the mainstream JVMs any time soon.




2. We can set up two different Contexts for the two servers, using 
something along these lines:


  Component component = new Component();
  Server server1 = new Server(Protocol.HTTPS, "host1.example.org", 
8443, null);
  Server server2 = new Server(Protocol.HTTPS, "host2.example.com", 
8443, null);

  component.getServers().add(server1);
  component.getServers().add(server2);

  SslContextFactory sslContextFactory1 = ...
  /* an SslContextFactory that will return an SSLContext with an 
X509KeyManager choosing the alias for "host1.example.org" */

  SslContextFactory sslContextFactory2 = ...
  /* an SslContextFactory that will return an SSLContext with an 
X509KeyManager choosing the alias for "host2.example.com" */


  server1.getContext().getAttributes().put("sslContextFactory", 
sslContextFactory1);
  server2.getContext().getAttributes().put("sslContextFactory", 
sslContextFactory2);


  // (I then add a couple of virtual hosts, one for each name.)


I've tried this, and it works.



Best wishes,

Bruno.



[1]
http://java.sun.com/j2se/1.5.0/docs/api/javax/net/ssl/X509KeyManager.html
[2]
http://mail.openjdk.java.net/pipermail/security-dev/2008-July/000225.html

Re: SSL + Virtual Hosts and Issue #489?

[Bruno Harbulot]

Bruno Harbulot wrote:

2. We can set up two different Contexts for the two servers, using 
something along these lines:


  Component component = new Component();
  Server server1 = new Server(Protocol.HTTPS, "host1.example.org", 8443, 
null);
  Server server2 = new Server(Protocol.HTTPS, "host2.example.com", 8443, 
null);

  component.getServers().add(server1);
  component.getServers().add(server2);

  SslContextFactory sslContextFactory1 = ...
  /* an SslContextFactory that will return an SSLContext with an 
X509KeyManager choosing the alias for "host1.example.org" */

  SslContextFactory sslContextFactory2 = ...
  /* an SslContextFactory that will return an SSLContext with an 
X509KeyManager choosing the alias for "host2.example.com" */


  server1.getContext().getAttributes().put("sslContextFactory", 
sslContextFactory1);
  server2.getContext().getAttributes().put("sslContextFactory", 
sslContextFactory2);


  // (I then add a couple of virtual hosts, one for each name.)


I've tried this, and it works.



To be more specific on setting up the sslContextFactory, if you're 
willing to try jSSLutils from the subversion repository (0.4-SNAPSHOT, 
rev 30), you should be able to use something like this:


jsslutils.sslcontext.X509SSLContextFactory sslContextFactory1 =
   new X509SSLContextFactory(keyStore, "keypassword", trustStore);

sslContextFactory1.setKeyManagerWrapper(new 
FixedServerAliasKeyManager.Wrapper("host1.example.org"));


server1.getContext().getAttributes().put("sslContextFactory", new 
JsslutilsSslContextFactory(sslContextFactory1));



Feedback welcome of course.


Best wishes,

Bruno.

Re: SSL + Virtual Hosts and Issue #489?

[Bruno Harbulot]

Hi all,

Bruno Harbulot wrote:

1. We assume there's going to be a single SSLContext common to all 
servers of the component created via an SslContextFactory (it's set up 
in the Context of the Component).


In theory, it should be possible to set up the SSLContext to use a 
custom X509KeyManager [1] that implements chooseServerAlias(String 
keyType, Principal issuers, Socket socket) to choose the appropriate 
alias depending on the listening socket that is used.
Unfortunately, I've tried, and the "socket" passed to that method is 
temporary socket that has almost the same characteristics as the actual 
one, but not all, especially not the local address, which is what we 
would need. I've just talked about it with the OpenJDK security team 
[2], but I wouldn't expect a fix in the mainstream JVMs any time soon.


Sorry, what I've said was wrong. It can work. There is a second call 
during the SSL handshake during accept, as discussed in this thread [2].


Therefore, it would be possible to choose an alias based on the actual 
socket and its local address.


Essentially, it's now a matter of providing a way to configure this:
   chooseServerAlias(String keyType, Principal issuers, Socket socket)


Best wishes,

Bruno.



[1]
http://java.sun.com/j2se/1.5.0/docs/api/javax/net/ssl/X509KeyManager.html
[2]
http://mail.openjdk.java.net/pipermail/security-dev/2008-July/000225.html

Re: Resource as an Observer...

[Bruno Harbulot]

Hi,

If you think of the Resource class in a Model-View-Controller pattern, 
you can think of the Resource the class that will implement the 
Controller (getRepresentation, acceptRepresentation, storeRepresentation 
-- probably a completely different terminology than your 'controller') 
which will provide you with the Views (the resulting representations). 
It's up to you to implement the Model as you wish: this could be the 
Observer of your Observable backend.


You probably shouldn't run anything that is likely to take some time 
within a Resource. Although nothing effectively prevents you from having 
a resource that does something and wait until it returns, it's doesn't 
seem like good practice to keep your clients hanging.


Best wishes,

Bruno.


Kit Plummer wrote:


Thanks Jerome.  Sure.

I have three different Resource classes.  The first one is a "session"
initialization mechanism which kicks off a backend controller.  That controller
does various things that need to happen before the "session" Resource can
return.  I'd like this controller to be a Thread/Runnable.  So, I was looking in
to the use of Java's Observer/Observable, to get the status from the controller
back to the "session" Resource, which would be the Observer.

Hope that's enough information.

(Funny, the post.gmane.org app wouldn't let me top-post.)

Kit

Re: XForm integration with the RestLet framework possible?

[Bruno Harbulot]

Yes... That's precisely my problem ;-) Many of our users have Macs too.

Funnily enough, the more and more we demonstrate our system (which is 
still a work in progress), the more people like this idea of having the 
web-service and the web-interface be the same. Although this 
web-interface was only meant to make it easier to debug and to show the 
progress of the work to a few people, it looks like we might have to 
make it more robust at some point if our users are more interested in 
it, in which case our handling of XForms should be capable of working 
with a wider variety of browsers. In this case, having something that 
doesn't rely on a FF plugin would be a good thing anyway.


Best wishes,

Bruno.


Klotz, Leigh wrote:

http://philipp.wagner.name/mozilla-xforms/ works in FF3, except for the
Mac. 


-Original Message-
From: news [mailto:[EMAIL PROTECTED] On Behalf Of Bruno Harbulot
Sent: Tuesday, July 08, 2008 4:41 PM
To: discuss@restlet.tigris.org
Subject: Re: XForm integration with the RestLet framework possible?

Hi,

Since Firefox 3, this plugin not available for FF3,...
Bruno.

Re: Routing problem

[Bruno Harbulot]

Hi all,

[EMAIL PROTECTED] wrote:

Thierry Boileau <[EMAIL PROTECTED]> wrote on 07/16/2008 04:32:30 AM:
1) to our minds, the routes "/foo" and "/foo/" identify two separate 
resources. Mostly because this has an impact on relative URIs. When we 
encountered this kind of issue when developping the o.r.Directory, we 
decided to addressed it by doign a redirection (redirection to the URI 
having the training "/").


Hi, Thierry-

Thanks for taking the time to respond to this.  Can you explain the 
circumstances under which "/foo" and "/foo/" would refer to different 
resources?  This seems non-intuitive to me, in terms of what I understand 
about ROA and REST, and in common usage on the Web, where the non-slash 
URI frequently, silently redirects to the trailing-slash-uri.  I think of 
it as just a user-friendly convenience I'm offering to my clients: if one 
of them forgets a trailing slash, it's still clear to me what they 
intended, and rather than giving them a 404, I can send back a 303.



That's always the case. "http://example.org/foo"; and 
"http://example.org/foo/"; are two distinct URIs.


Apache Httpd has a module for this [1] which is activated by default. 
Basically, what's almost invisible is that if you point your browser to 
an Apache server at "http://example.org/foo"; (where "foo" is a 
directory), there's an immediate 302 response redirecting the browser to 
"http://example.org/foo/";.
The only case where it's equivalent is the case where the trailing slash 
would be positioned immediately after the host name.


I agree it would be good to have such a mechanism in Restlet, but the 
problem isn't specific to Restlet.

A good Restlet-based use-case (if you try to click on the links) is this:
(1) http://www.restlet.org/documentation/1.1
and
(2) http://www.restlet.org/documentation/1.1/


One of the main points of REST is that the client should be guided from 
one resource to another using the hypermedia (in simpler terms, the href="..." /> links or equivalent), so if you get the entry point right, 
the resources that follow should be fine too (just make sure there's a 
trailing slash in the links your resource provide).
Of course, the tricky case is the case where the entry point isn't right 
(see link (1) above), in which case the relative URLs this page leads to 
are incorrect. This sort of mistake is easy to make, especially with 
browsers that assist you when you start typing an address in the 
location bar.
Having a routing mechanism that would make it possible to turn on the 
feature as implemented for Directory for other things than directories 
would be useful indeed. To solve this at the moment, I make sure the 
users start using the system via a correct URI; all the subsequent URIs 
they get have the appropriate trailing slashes, since the representation 
that lead them to these other resources have been generated accordingly.



Best wishes,

Bruno.

[1] http://httpd.apache.org/docs/2.2/mod/mod_dir.html

Re: SSL + Virtual Hosts and Issue #489?

[Bruno Harbulot]

Alex Milowski wrote:

On Wed, Jul 16, 2008 at 2:32 AM, Jerome Louvel <[EMAIL PROTECTED]> wrote:

Hi Alex,

I have added a paragraph on "Confidentiality" in the "Securing applications"
page covering this topic:
http://wiki.restlet.org/docs_1.1/g1/13-restlet/29-restlet/99-restlet/46-rest
let.html

At some point, it might makes sense to split up this page into several ones.


Thanks.

I think it would be good to have some ssl-specific information make its
way into the connector documentation as an example.

That is, there is a simple example here:

   
http://wiki.restlet.org/docs_1.1/g1/13-restlet/27-restlet/37-restlet/38-restlet.html

Maybe we could have about ssl configuration there as well.  Of course, the
parameters are specific to the server helper...


Actually, using the SslContextFactory, the parameters can now be 
consistent across the Grizzly, Jetty and Simple HTTPS connectors. We're 
currently debating how it should be configured (see issue 489, feel free 
to join in): parameters vs. instances.


I reckon that, for the DefaultSslContextFactory, parameters would 
definitely make more sense. The current behaviour is to be able to pass 
to its init() method a series of parameters that will more or less 
follow the previous style of parameters. (It doesn't set any trust 
manager, which instead use the values set in the javax.net.ssl.* system 
properties as default).


The DefaultSslContextFactory wouldn't help choosing an alias. I guess it 
would be feasible to have a fixed alias (in a similar way as I've done 
it in jSSLutils with FixedServerAliasKeyManager -- see one of the 
previous messages in this thread), but that wouldn't really help for 
your initial problem, unless you use a different context per connector.



If you want to be able to use a single SSLContext between your two 
sockets, you're going to need a KeyManager that is able to pick the 
right alias depending on which socket is used.
In jSSLutils, the FixedServerAliasKeyManager I've implemented picks one 
by always returning the same value (the one with which it's been 
constructed). What we'd need for would be a way to configure such a 
KeyManager so that it would look like this:


  class SocketSelectorKeyManager implements X509KeyManager {
 private final "SomeInformation" someInformation;
 public SocketSelectorKeyManager(SomeInformation someInformation) {
this.someInformation = someInformation;
 }
 public String chooseServerAlias(String keyType, Principal[] 
issuers, Socket socket) {
String alias = "makeSomeDecisionBasedOn"(someInformation, 
socket.getLocalSocketAddress()); // (or other arguments)

return alias;
 }
 ...
   }

What "SomeInformation" and "makeSomeDecisionBasedOn" should be like 
could depend on many factors. I could try to implement one of these in 
jSSLutils, but I'm not sure how you'd like to be able to configure such 
a KeyManager. Any preferences?



Regarding the documentation, I'm planning to document the 
jSSLutils-specific settings on the jSSLutils website when I get the time 
to do so (probably next week). I'll try to document the 
DefaultSslContextFactory in the Restlet doc too (although I'm not sure I 
have access to the wiki).



Best wishes,

Bruno.

Server with multiple protocols and a single port?

[Bruno Harbulot]

Hello,

I've just had a look at the Component XML configuration mechanism and 
how it's implemented. I've noticed that there can be several protocols 
but only one port in the attributes.
This matches the interface of the Server class, the constructors of 
which can take a list of protocols, but always with a single port value.
I'm a bit confused about this: how could a server listen for both HTTP 
and HTTPS on the same specified port? Is there any use case for this?


Best wishes,

Bruno.

Re: Server with multiple protocols and a single port?

[Bruno Harbulot]

Hi Jerome,

Interesting. I suppose that can't work with protocols where the server 
starts the talking (for example POP3, IMAP4, SMTP). I'd be a bit 
concerned about sharing a port for HTTP and HTTPS, but this might not be 
such a bit security problem so long as the client is aware it must use 
SSL when required.


Best wishes,

Bruno.


Jerome Louvel wrote:

Hi Bruno,

This is rare but indeed possible. For example Grizzly has a feature called
"port unification" with some protocol finder logic:
http://weblogs.java.net/blog/jfarcand/archive/2006/11/one_port_to_rul.html

Best regards,
Jerome

-Message d'origine-
De : news [mailto:[EMAIL PROTECTED] De la part de Bruno Harbulot
Envoyé : lundi 28 juillet 2008 00:15
À : discuss@restlet.tigris.org
Objet : Server with multiple protocols and a single port?

Hello,

I've just had a look at the Component XML configuration mechanism and 
how it's implemented. I've noticed that there can be several protocols 
but only one port in the attributes.
This matches the interface of the Server class, the constructors of 
which can take a list of protocols, but always with a single port value.
I'm a bit confused about this: how could a server listen for both HTTP 
and HTTPS on the same specified port? Is there any use case for this?


Best wishes,

Bruno.

Re: Server with multiple protocols and a single port?

[Bruno Harbulot]

I don't think it's really a matter of connection, the problem is which 
of the client or server sends the first bytes.


A server can potentially distinguish between HTTP or SSL, because in 
both cases, the client sends the first message ("GET / ..." or 
clientHello message in SSL).


In contrast, for protocols POP3, IMAP4, SMTP, it's the server that sends 
the first message (a welcome/opening message). It seems difficult for 
the server to adapt to which protocol to use (and thus which initial 
message it's supposed to send) if the first client packets have to be a 
response to that initial server message.


Here are a couple of quotes from RFC 2821 (SMTP):
"3.1 Session Initiation
   An SMTP session is initiated when a client opens a connection to a
   server and the server responds with an opening message."
"3.2 Client Initiation
   Once the server has sent the welcoming message and the client has
   received it, the client normally sends the EHLO command to the
   server, indicating the client's identity."


Best wishes,

Bruno.


Jerome Louvel wrote:

Hi Bruno,

I think they buffer a certain number of bytes to attempt to detect
protocols, before conversation actually starts. 


So it could also work for connected protocols no?

Best regards,
Jerome


-Message d'origine-----
De : news [mailto:[EMAIL PROTECTED] De la part de Bruno Harbulot
Envoyé : mardi 29 juillet 2008 14:37
À : discuss@restlet.tigris.org
Objet : Re: Server with multiple protocols and a single port?

Hi Jerome,

Interesting. I suppose that can't work with protocols where the server 
starts the talking (for example POP3, IMAP4, SMTP). I'd be a bit 
concerned about sharing a port for HTTP and HTTPS, but this might not be 
such a bit security problem so long as the client is aware it must use 
SSL when required.


Best wishes,

Bruno.


Jerome Louvel wrote:

Hi Bruno,

This is rare but indeed possible. For example Grizzly has a feature called
"port unification" with some protocol finder logic:
http://weblogs.java.net/blog/jfarcand/archive/2006/11/one_port_to_rul.html

Best regards,
Jerome

-----Message d'origine-
De : news [mailto:[EMAIL PROTECTED] De la part de Bruno Harbulot
Envoyé : lundi 28 juillet 2008 00:15
À : discuss@restlet.tigris.org
Objet : Server with multiple protocols and a single port?

Hello,

I've just had a look at the Component XML configuration mechanism and 
how it's implemented. I've noticed that there can be several protocols 
but only one port in the attributes.
This matches the interface of the Server class, the constructors of 
which can take a list of protocols, but always with a single port value.
I'm a bit confused about this: how could a server listen for both HTTP 
and HTTPS on the same specified port? Is there any use case for this?


Best wishes,

Bruno.

Re: SSL + Virtual Hosts and Issue #489?

[Bruno Harbulot]

Hello,


Following the changes in the way Components can be configured (latest 
subversion revisions), configuring SSL to use an SslContextFactory is 
now possible this way:


  1. Using the DefaultSslContextFactory:

http://www.restlet.org/schemas/1.1/Component";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.restlet.org/schemas/1.1/Component";>




		value="com.noelios.restlet.util.DefaultSslContextFactory" />














  2. Using the PkixSslContextFactory (newly added, with jSSLutils 0.4):

http://www.restlet.org/schemas/1.1/Component";
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance";
xsi:schemaLocation="http://www.restlet.org/schemas/1.1/Component";>




		value="com.noelios.restlet.ext.ssl.PkixSslContextFactory" />


















There can be multiple "crlUrl" parameters.

In addition, there are a couple of other parameters that can be set:
- "sslServerAlias", which will use a particular alias from the keystore,
- "disableCrl", which should be set to "true" if you don't want to use CRLs.


Feedback welcome (especially if it doesn't work as intended!)


Best wishes,

Bruno.

Re: How to create multiple https connector with different certificates?

[Bruno Harbulot]

Hi,

You would need one of the latest subversion revisions to do this. Some 
changes regarding this problem are very recent (yesterday).


You can do this by having a Context per Server and a distinct 
SslContextFactory in each.


The documentation will improve, meanwhile you can check these two 
messages [1][2].


Something like this should work:
Component component = new Component();

Server server1 = component.getServers().add(Protocol.HTTPS, 
"localhost", 8080);

Series param1 = server1.getContext().getParameters();

param1.add("sslContextFactory","com.noelios.restlet.ext.ssl.PkixSslContextFactory");
param1.add("keystorePath","/path/to/keystore1.p12");
param1.add("keystorePassword","...");
param1.add("keystoreType","PKCS12");
//...

Server server2 = component.getServers().add(Protocol.HTTPS, 
"localhost", 8082);

Series param2 = server2.getContext().getParameters();

param2.add("sslContextFactory","com.noelios.restlet.ext.ssl.PkixSslContextFactory");
param2.add("keystorePath","/path/to/keystore2.p12");
//...

You'll find an up-to-date list of parameters described in [2]. In 
particular, if you are using the same keystore, you should be able to 
choose an alias for a given context using the 'sslServerAlias' parameter.



These changes should be in Restlet 1.1-M5 when it's out (I think it's 
going to be soon).



Best wishes,

Bruno.

[1] http://restlet.tigris.org/servlets/ReadMsg?list=discuss&msgNo=5711
[2] http://restlet.tigris.org/servlets/ReadMsg?list=discuss&msgNo=5886


Bruce Lee wrote:

Hi,

I'm trying to setup a host with the following address but have different
certificate.

https://localhost:8080

https://localhost:8082

My problem is although the server connectors seems to start correctly, when I
check the certificate for each of the site, it shows the same certificate. I'm
not sure if I need to setup something else.
I'm using Restlet 1.0.10 with Jetty connector and here is how I setup my 
connectors.


component = new Component();
// setting up server connectors
ServerList serverConnectors = component.getServers();
Server server = serverConnectors.add(Protocol.HTTPS, "localhost", 8080);
// setup first certificates
--- server.getContext().getParameters().add( etc etc
server = serverConnectors.add(Protocol.HTTPS, "localhost", 8082);
// setup second certificates
--- server.getContext().getParameters().add( etc etc

component.getDefaultHost().attach("/", router);

component.start();

Re: How to create multiple https connector with different certificates?

[Bruno Harbulot]

Hi,

Bruce Lee wrote:

Thanks for the information, I guess we will have to wait until Restlet 1.1
becomes stable so we can try out the feature.


I've put some documentation in the wiki.
If possible, you could this try when Restlet 1.1-M5 is out (probably 
easier than subversion builds). This would help to have feedback and bug 
reports, if any, before the stable release.


Best wishes,

Bruno.

Re: HTTP Negotiate and Basic authentication

[Bruno Harbulot]

Hi Roman,

Here is my experimental SPNEGO Filter:
  http://git.kato.mvc.mcc.ac.uk/bruno/spnegofilter.git/

It provides a Negotiate and a Basic challenge at the same time.
It works at least for small tests, but it's definitely not ready for 
production usage. I haven't used much of the existing Guards and related 
classes; I haven't looked deeply into what would need to be changed for 
this particular filter yet. You'll need Restlet 1.1-M5 or something 
close enough if you want to try it out, because it uses multiple 
challenges (1) and the new context system. It also requires Java 6.


Best wishes,

Bruno.


(1) http://restlet.tigris.org/issues/show_bug.cgi?id=457

Roman Geus wrote:

Hello all

I'm new to Restlet and would like to implement a REST interface for an 
existing application using Restlet and JAX-RS.


I need to support both HTTP Negotiate and HTTP Basic authentication vs 
an Active Directory server.


The Restlet server should offer both authentication schemes and the 
client may choose one of them and send the appropriate credentials. The 
Restlet server will then validate the credentials using a Kerberos 
server (Active Directory).


I don't know how to implement the dual HTTP authentication scheme in 
Restlet. From looking at the code, it seems, that a custom Guard can 
only implement a single scheme. How can I support a second 
authentication scheme?


Also, Negotiate authentication is not supported out-of-the-box and the 
Negotiate ChallengeScheme is not predefined. Is it possible to support 
the Negotiate scheme without modifying the Restlet code?


Any help with this (example code, hints, pointers, ...) would be highly 
appreciated.


Thanks,
Roman

--
Roman Geus
Paul Scherrer Institut
AIT
Scientific Computing
5232 Villigen PSI
Switzerland

Tel: +41 56 310 54 85
Fax: +41 56 310 36 49

e-Mail: [EMAIL PROTECTED]

Re: HTTP Negotiate and Basic authentication

[Bruno Harbulot]

Roman Geus wrote:

Hi Bruno

Thanks for sharing your experimental SPNEGO Filter!

I never used "git" before. To download your code I tried the following 
(and failed)
$ git clone http://git.kato.mvc.mcc.ac.uk/bruno/spnegofilter.git/ 
spnegofilter

Initialized empty Git repository in /home/geus/gitwork/spnegofilter/.git/
Cannot get remote repository information.
Perhaps git-update-server-info needs to be run there?

Is it a problem on my end?


Ah, sorry, it should work now. I must admit I haven't been using git for 
long.



It's not a major issue though, since I can download the individual files 
using a web browser.


It's also possible to get an archive (tgz) by clicking on 'snapshot' in 
the list of commits (the one on the line with the 'master' icon makes 
more sense).



Best wishes,

Bruno.

Re: Knowing if a client disconnected?

[Bruno Harbulot]

Hi Marc,

I think what Kevin meant (and was more along my interpretation of the 
original question) is that you can know that a socket has been closed 
before attempting to write to it, but you cannot know that it's going to 
be open for writing until you actually write to it. As Jerome pointed 
out, guaranteed delivery is a more subtle problem that has to be handled 
differently.


Best wishes,

Bruno.


Marc Larue wrote:

Hi Paul,

Rupy has this functionallity built in: http://rupy.googlecode.com

You get a Service.session(Session, DISCONNECT) event when all of the TCP 
connections for a session have been forcibly closed.


Unfortunately this doesen't work if you are behind an apache proxy, since 
it caches and reuses TCP connections.


Cheers,

/marc

On Wed, 13 Aug 2008, Kevin Conaway wrote:


I don't think its possible to check on the state of a Socket without
actually writing to it.

Why do you need to know if a client is still active? Perhaps you could
restructure your problem in a different manner?

On Wed, Aug 13, 2008 at 3:30 PM, Jerome Louvel <[EMAIL PROTECTED]>wrote:


Paul,

Beside intercepting JDK log messages, looking for those IO exceptions,
there
is indeed currently no way to intercept those errors and act on them.
That's
why I suggested a RFE.

As a more general thought, you will never be 100% sure that a client got
your response and successfully processed it unless the client confirms it
to
you via a separate request. For example a client crash could occur right
after he read your response...

But if we can give you more control at Restlet API level, I think this is
valuable.

Best regards,
Jerome Louvel

Re: SSL problem

[Bruno Harbulot]

Hi Christy,

File keystoreFile = new File("/Users/christyring/.keystore",".keystore"); 
component.getContext().getParameters().add("keystorePath",keystoreFile.toURI().toASCIIString());


In this, keystoreFile.toURI() is 
"file:/Users/christyring/.keystore/.keystore", which is probably not 
what you were intending.


The "keystorePath" parameter expects pathname, not a URI. Something like 
this should work better:

component.getContext().getParameters().add("keystorePath","/Users/christyring/.keystore");

This should work for locations other than ~/.keystore too.

I've also noticed that the certificate you're using uses "cn=Christy 
Ring". This won't prevent your server from starting, but the clients 
will complain because the CN doesn't match the hostname. You must use 
the host name of the server in the CN field, for example 
"cn=www.example.org".



Best wishes,

Bruno.


Christy Ring wrote:
Guys I've being trying to get a query answered on the issues list with 
no success, looking at the list contents I probably should have posted 
this on the discuss list. 

I'm having problems getting SSL working, can anyone here help with this. 
 This is my final stumbling block if I get over this alls looking well.


...

Further investigation is showing that the following code is being ignored!

 
component.getContext().getParameters().add("keystorePath",keystoreFile.toURI().toASCIIString());

component.getContext().getParameters().add("keystorePassword","jboxXXX");

component.getContext().getParameters().add("keyPassword","jboxXXX");


And that the code is using the defaults.  Is component.getContext the 
correct way of setting these parameters?



Can someone confirm that the BasicHttpsServer example from the book is 
working with 1.1-M5?  If someone has a testcase can you check it also 
works if the keystore is not in "${user.home}/.keystore"



Thanks.









On 8 Aug 2008, at 09:47, Christy Ring wrote:


Guys first posting.  Using Restlet 1.1m5.


I've been experimenting with Restlet (vs Jersey) as one approach to 
a solution we are working on.   Currently I am trying to get SSL 
working with the Simple connector.  I've read through the previous 
posts on the configuration of this and I believe I am configuring it 
correctly.  

When I startup my mainline I get the keystore tamper error. 

Exception in thread "main" java.io.IOException: Keystore was 
tampered with, or password was incorrect

at sun.security.provider.JavaKeyStore.engineLoad(JavaKeyStore.java:768)



I am running on a mac with Java 5 and creating a new keystore in my 
home directory as follows:


keytool -genkey -dname "cn=Christy Ring, ou=JBox, o=Vennetics, 
c=GB" -alias vennetics -keypass jboxXXX -keystore .keystore 
-storepass jboxXXX
 


Listing the keystore I get the following:


$  keytool -list
Enter keystore password:  jboxXXX

Keystore type: jks
Keystore provider: SUN

Your keystore contains 1 entry

vennetics, Aug 7, 2008, keyEntry,
Certificate fingerprint (MD5): 
B9:D9:07:98:8B:92:B2:FF:B0:F4:D7:9C:D8:19:FB:16





My main line looks like the following:

public static void main(String[] args) throws Exception {
// Create a new Component.
Component component = new Component();
File keystoreFile = new File("/Users/christyring/.keystore", 
".keystore");

component.getContext().getParameters().add("keystorePath",keystoreFile.toURI().toASCIIString());

component.getContext().getParameters().add("keystorePassword","jboxXXX");

component.getContext().getParameters().add("keyPassword","jboxXXX");
 

// Add a new HTTPS server listening on port 8183.

component.getServers().add(Protocol.HTTPS, 8183);

// Attach the sample application.
component.getDefaultHost().attach("/jbox/v2",new 
WidgetApplication(component.getContext()));

// Start the component.

component.start();


...
 

Can anyone suggest what I'm doing wrong?  Or provide an concrete 
example for me to compare with?  Also can you confirm that I have 
created my certificate correctly when creating the keystore?



As an aside, I really like how you have implemented the api and how 
the components are constructed, for REST it feels much more natural 
than what is described in JSR 311, I hope that you will continue to 
maintain this.  

I read that you offer support for 311 annotations, I hope that this 
does not become the defacto way of doing thinks in restlets. 





Regards,
[EMAIL PROTECTED] 









Regards,
[EMAIL PROTECTED] 

Re: SSL problem

[Bruno Harbulot]

Hi Christy,

Christy Ring wrote:
I wasnt aware of the certificate issue, thanks.  I've modified the 
keytool command to reflect the changes you suggest as follows, deleted 
the .keystore and recreated it.  I assume this is all I have to do with 
the keystore to get up and running?


keytool -genkey -keyalg RSA -dname "cn=www.vennetics.com 
, ou=JBox, o=Vennetics, c=GB" -alias vennetics 
-keypass jbox123 -keystore /Users/christyring/.keystore -storepass jbox123 


Yes, this should be sufficient to generate a self-signed certificate, 
which may be enough depending on your requirements. This is likely to be 
a problem if you deploy it for a wide audience.



Bruno do you have an application that you confirm this feature works 
with 1.1-M5?  To test myself I modified the keystore, keystorePassword 
and keyPassword of the BasicHttpServer example that came with 1.1-M5 
with my details, nothing else and ran this, it failed.   I've pasted the 
code below with my changes. 


final File keystoreFile = new File("d:\\temp\\certificats", 
"myServerKeystore");

// Component declaring only one HTTPS server connector.
final Component component = new Component();
component.getServers().add(Protocol.HTTPS, 8182);
component.getDefaultHost().attach("/helloWorld", restlet);

// Update component's context with keystore parameters.
component.getContext().getParameters().add("keystorePath", 
"/Users/christyring/.keystore");

component.getContext().getParameters().add("keystorePassword", "jbox123");
component.getContext().getParameters().add("keyPassword", "jbox123");


I had missed something: now that the Contexts have been split, these 
settings should be configured in the Server context:


 Server server = component.getServers().add(Protocol.HTTPS, 8182);
 component.getDefaultHost().attach("/helloWorld", restlet);

 server.getContext().getParameters().add("keystorePath", 
"/Users/christyring/.keystore");

 server.getContext().getParameters().add("keystorePassword", "jbox123");
 server.getContext().getParameters().add("keyPassword", "jbox123");

That's certainly something we should clarify in the documentation [1][2].

I've just tried this with a test keystore on OSX with Restlet 1.1-M5 and 
it worked.


Best wishes,

Bruno.


[1] 
http://wiki.restlet.org/docs_1.1/g1/13-restlet/29-restlet/99-restlet/46-restlet.html

[2] http://wiki.restlet.org/docs_1.1/g1/43-restlet/153-restlet.html

Re: Virtual hosts - no domain only ip address

[Bruno Harbulot]

(I sent this message yesterday, but it didn't get through. Apologies if 
you get duplicates.)



Hi Christy,

Christy Ring wrote:

Hi all,

I am running a VM on a host, currently I have a work example that is 
routing requests to a resource at https://localhost:8183/jbox/v1/


The virtual machine can see the host through the following ip address 
192.168.0.2


 From the VM when I send a request to the resource 
https://192.168.0.2:8183/jbox/v1/ I get the following:


com.vennetics.jbox.fs.api.v1.WidgetApplication1047055737)[WARNING|Thread-2|8:35:58.0959]: 
A resource should normally have at least one variant added by calling 
getVariants().add() in the constructor. Check your resource 
"https://192.168.0.2:8183/jbox/v1/";.


org.restlet.Component (1524987604)[INFO|Thread-2|8:35:58.0968]: 
2008-08-1908:35:58127.0.0.1--8183GET
/jbox/v1/-4043310https://192.168.0.2:8183Mozilla/4.0 
(compatible; MSIE 6.0; Windows NT 5.1; SV1; InfoPath.2)-



I expect this to work by defining a VirtualHost, even though I have no 
domain defined.  I have defined my VirtualHost as follows:


It doesn't sound like it's related to the VirtualHost, but to the
Resource class behind /jbox/v1/. Perhaps you haven't added any variant.
This can be done, for example, by adding something like this in the
'init' method of your Resource class:
getVariants().add(new Variant(MediaType.TEXT_HTML));

The media type will depend on the representations you wish to offer.


Best wishes,

Bruno.

Re: PUT method without body entity

[Bruno Harbulot]

Hi Vincent,

We had this discussion a few month ago:
http://thread.gmane.org/gmane.comp.web.services.rest/8046

In short, the conclusion was that a PUT without an entity wasn't 
allowed, but a PUT with a "Content-Length: 0" entity was.



Strictly speaking, the query string in the URI is part of the URI. Thus, 
every time you change this query string, you effectively make a request 
to a different resource potentially. Perhaps the problem you're having 
is a symptom showing that these parameters ought to be in the body of 
the request.


Best wishes,

Bruno.

Vincent Ricard wrote:

Hi,

My application use the PUT methods to update some business objects, but
some of these PUT methods do not expect an entity (the value is a string
passed in the query string). RESTlet returns an HTTP 400 status.

Is it a strict behavior required by the RFC?
I expected the same behavior as the handlePost() method: a log trace, then
a call to storeRepresentation with a 'null' param.

So, is it a bug of an HTTP "feature"?

Regards,

Re: client-side support for Negotiate authentication scheme

[Bruno Harbulot]

Hi Roman,

When you take someone else's code and modify it, you might want to look 
at the beginning of the file (or the licence file), especially when you 
post a file to a public mailing list and thus have no chance of being 
able to amend it once archived:



Copyright (c) 2008, The University of Manchester, United Kingdom.
All rights reserved.

Redistribution and use in source and binary forms, with or without 
modification, are permitted provided that the following conditions are met:


* Redistributions of source code must retain the above copyright notice, 
  this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright 
  notice, this list of conditions and the following disclaimer in the 
  documentation and/or other materials provided with the distribution.
* Neither the name of the The University of Manchester nor the names of 
  its contributors may be used to endorse or promote products derived 
  from this software without specific prior written permission.


THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" 
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE 
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE 
ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE 
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR 
CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF 
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS 
INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN 
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) 
ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE 
POSSIBILITY OF SUCH DAMAGE.



This being said, I'm glad you found it useful. In principle, I'm in 
favour of including it into the Restlet code. However, the reason I 
published it separately in the first place was because it was a small 
prototype and I felt this feature should be part of a wider rethink of 
the Guard-related classes. This is an objective that Jerome set for 
Restlet 1.2, so let's wait for 1.1 final first, although of course we 
can already start to talk about it and experiment with new features.



Cheers,

Bruno.


Roman Geus wrote:

Hi Stephan

The NegotiateFilter, together with an example client and server is 
attached to this post.


You are free to add this code to the Restlet codebase if you find it 
useful. Since I borrowed some ideas and code from Bruno Harbulot's 
SpnegoFilter, he should be consulted as well. Also IMHO more testing is 
needed.


The README file:

NegotiateFilter is a Restlet filter that implements Negotiate and Basic
authentication on both the client and the server side. The server 
accepts both

SPNEGO and Kerberos v5 GSSAPI tokens.

It comes with a runnable test client and test server.

The code has only been tested in a Windows Active Directory 
environment but

should work with any Kerberos v5 infrastructure.

The code has been tested with Restlet 1.1rc1 with a patched version of 
the
com.noelios.restlet.authentication.AuthenticationUtils.parseAuthenticateHeader() 


method (see mailing list).

The jaas.conf file and the some constants in ExampleClient.java and 
some system

properties contain site-specific information and need to be adjusted.

Also a working keytab file and krb5.conf file (or similar) are needed.

See the *.launch file for information how to set the system properties.

NegotiateFilter is based on Bruno Harbulot's SpnegoFilter.

Roman Geus

Cheers,
Roman

Re: client-side support for Negotiate authentication scheme

[Bruno Harbulot]

Hi Roman,

Roman Geus wrote:

Hello Bruno

I'm sorry about not paying more attention to the licensing issues. I 
meant no harm and I am certainly not trying to take credit for your work.
Just to explain: the code I posted is not a quick rip-off of your 
filter. I put considerable amount of time into rewriting, refactoring 
and adding new functionality.
It was my understanding that NegotiateFilter would not fall into 
category of "redistribution" or "modification" of your SpnegoFilter and 
thus not violate the copyright. However I'm not experienced in these 
legal matters.


Don't worry, I'm not upset, it's nice of you to have acknowledged my 
work and I do realise you've done some substantial work on this too. 
It's some code that I've planned to contribute to Restlet anyway at some 
point, so it's not a major issue, but I have signed the Restlet JCA; I'm 
not sure you have.


I'm not a legal expert either, but I think it would have been in your 
interest to send your code with a licence (pending JCA integration), 
since many people might assume that what is made public is in the public 
domain (although I don't think it legally is -- it's probably the 
opposite, but a licence would clarify things). This is in fact why I put 
this licence on my code in the first place (also because the copyright 
is actually held by my employer), not because I didn't want it in the 
Restlet code.


My understanding of the (BSD) licence I've used is that putting it at 
the bottom of the README file saying something like "some of this code 
was based on code distributed with this licence: ..." would have been 
sufficient.
As the (representative of the) copyright holder, this is something that 
only I (or another representative) can waive when contributing through 
the Restlet JCA, which I'm happy to do in this instance.



Cheers,

Bruno.

Re: client-side support for Negotiate authentication scheme

[Bruno Harbulot]

Hi all,

I'd be happy to put it in the Restlet repository. Jerome, do you have 
any preferred place in the repository for this?
By the way, I had mentioned I had started some work on the structure of 
the Guards, etc. (mostly for my project's needs but that could be used 
for 1.2). Perhaps it could be time to put it somewhere in the Restlet 
code-base too.  I was going to wait for the 1.1 release, but if Roman is 
doing some work on this type of problem too, we might as well try to 
coordinate our work.


Best wishes,

Bruno.


Roman Geus wrote:

Hi Jerome

Thanks for pointing out the necessary steps.

I'll wait until Bruno's code has been contributed to the repository and 
then do my part.


Best regards,
Roman


Jerome Louvel wrote:

Hi Roman, Bruno and all,
 
Roman, thanks for reporting this parsing bug with WWW-Authenticate 
HTTP header. I have just fixed it in SVN trunk.
 
Regarding the support for SPNEGO, I've updated the related RFE with a 
link to Bruno's original filter and another one back to this thread. 
I've also changed the target milestone of this RFE to 1.2 as it seems 
there is a good chance we could effectively add support for it.
 
"Support SPNEGO authentication"

http://restlet.tigris.org/issues/show_bug.cgi?id=444

Re: Restlets contained within servlets

[Bruno Harbulot]

Hello,

Simon Reinhardt wrote:

Hugh Acland wrote:
So in an ideal world where one's IT budget was larger than management 
have given you would have a dedicated restlet 'box' serving only 
restlets on port 80. The problem i have is that i am constrained to 
one physical server which has apache on 80, glassfish on 8080 and 8181 
and now i need to set up the restlets on another port. I tried many 
moons ago to get apache to pass through to glassfish on certain 
uri-stems but i ended up punching to death three monitors in thr 
process. now i just use the : in the client uri. don't like 
doing it though as it exposes your architecture to evil-doers. Perhaps 
using the servlet as aproxy is the best way forward..


Restlet also has an adaptor for AJP so you could use mod_proxy_ajp 
 to go directly 
from Apache to your Restlet app.

Would that be an option?


This should work, indeed. I've been using mod_jk with AJP too. (I 
haven't been able to use mod_proxy_ajp yet, since it doesn't support 
passing the full chain of client certificates when using SSL, yet.)
Using AJP relies on the Jetty connector (which works fine), or perhaps 
on Restlet being deployed within something like Tomcat, itself behind 
Apache Httpd (definitely a bit more convoluted, but this could be a 
solution if what you can deploy is limited).


Another option would be to use the mod_proxy_http in reverse proxy, 
which is similar to mod_proxy_ajp, except that it can talk HTTP to a 
container in the back-end, thus leaving more options open regarding the 
choice of connector. In fact, a single front-end Apache Httpd could be 
talking to a number of containers/connectors behind it: Glassfish, 
Restlet, etc.


This approach can be quite handy if you want some flexibility in terms 
of deployment. For example, I had a:

 - /myapp/* -> talking to the stable version of my application and
 - /myapptest/* -> talking to the development version, perhaps running 
within the latest snapshot of Restlet.

This can make rolling out new versions a bit smoother.


Best wishes,

Bruno.

Re: Authenticating and other thoughts

[Bruno Harbulot]

Hi Hugh,

Hugh Acland wrote:
And here is my main reservation about this wonderful Restful world of 
distributed computing: how do we authenticate and authorize across the web in 
a way whereby one web-service (in London), which might be happy dealing with 
the client’s request, then gets to a point in its logic execution where it 
needs to enlist the help of another web-service (in Tokyo). If the Tokyo web-
service (web-service-san?!) is just providing the temperature then there is 
probably no need to authenticate but if London (web-service-old-chap?!) wants 
to ask Tokyo to transfer $100,000 to web-service-cowboy (Texas) then the 
chances are some how the original security credentials must be parsed around 
like a children’s party game. And children’s party games always end in tears. 
Someone always spoils it. So is the current authentication/authorization 
model  - or lack of clarity of purpose – hindering mass take-up of this 
technology? From a management perspective, the old ways of doing things – thin 
client, massive load on clustered servers running guargantuan enterprise 
application server stacks and Berlin-wall style firewall behind which sits all 
the processing logic and firepower – makes life a lot more secure.


The problems you're talking about are not specific to REST. Credential 
delegation can be a problem, but there are solutions. Some of them, like 
Kerberos, have been around for a long time. This type of problem is in 
fact one of the main challenges that Grid-computing is addressing.


Many of this solutions can be supported by Restlet, or soon will be. 
We've started some work on SPNEGO (relevant for Kerberos delegation). 
The SSL extension can accept GSI proxy certificates, via the jsslutils 
library. It could also support Attribute Certificates (RFC 3281) for 
example (it's not in jsslutils yet, but it definitely could be).


You'll find, however, that even if the technology is there, the main 
problems are a matter of policies between institution. If your users or 
services in London, Tokyo and Texas all belong to the same institution, 
your could deploy something that uses Kerberos and a single KDC, for 
example. If not, federating multiple administrative domains to trust 
each others' assertions of credentials can be legally difficult 
(whatever the technology behind). On a more technical note, getting 
these institutions to deploy systems that can talk to each other is also 
a matter of policy (to this extent, REST might help); getting those who 
deploy the systems to trust the tools that implement their security 
isn't easy, because the models they implement are not simple, and 
because there is an inherent tangling with the legal and political side 
of security. I've left out discussion on educating users about the 
security of your system, which shouldn't be neglected of course.


Security through firewalls may look more secure, but certain security 
mechanism are either (a) too tight, thus preventing the users from 
actually performing whatever task the system is meant to do (that, 
you're sure, some managers will complain about, quite rightly so in my 
opinion) or (b) too complex, in which case, some users won't even bother 
using the system securely. Security is an exercise that consists of 
finding the right balance.



Best wishes,

Bruno.

Re: Consuming a REST response

[Bruno Harbulot]

Hi,

buzzterrier wrote:

I think I was missing the forest for the trees on this. I am kind of a framework
junkie, but in hindsight since I am only consuming the rest response I don't
really need restlets at all. Basically I just need to suck the response into a
dom, and then use jaxb with annotations to create the objects. 


Restlet is not just server-side, it also provides you with client 
connectors. You should then be able to use tools such as JAXB or 
XmlBeans from the representations obtained using these connectors indeed.


Best wishes,

Bruno.

Re: client-side support for Negotiate authentication scheme

[Bruno Harbulot]

Hi Roman and Jerome,

Sorry for the delay. I've just added the tarball to the issue tracker:
  http://restlet.tigris.org/issues/show_bug.cgi?id=444

Best wishes,

Bruno.

Jerome Louvel wrote:

Hi Bruno,

I would suggest that you attach a zip with your source code to the existing
issue in the tracker (or a new one).

Once, we create the 1.1 branch, we could use the trunk to land this but it
is a bit premature for now.

Best regards,
Jérôme Louvel
--
Restlet ~ Founder and Lead developer ~ http://www.restlet.org
Noelios Technologies ~ Co-founder ~ http://www.noelios.com


-Message d'origine-
De : news [mailto:[EMAIL PROTECTED] De la part de Bruno Harbulot
Envoyé : mercredi 1 octobre 2008 12:50
À : discuss@restlet.tigris.org
Objet : Re: client-side support for Negotiate authentication scheme

Hi all,

I'd be happy to put it in the Restlet repository. Jerome, do you have 
any preferred place in the repository for this?
By the way, I had mentioned I had started some work on the structure of 
the Guards, etc. (mostly for my project's needs but that could be used 
for 1.2). Perhaps it could be time to put it somewhere in the Restlet 
code-base too.  I was going to wait for the 1.1 release, but if Roman is 
doing some work on this type of problem too, we might as well try to 
coordinate our work.


Best wishes,

Bruno.


Roman Geus wrote:

Hi Jerome

Thanks for pointing out the necessary steps.

I'll wait until Bruno's code has been contributed to the repository and 
then do my part.


Best regards,
Roman


Jerome Louvel wrote:

Hi Roman, Bruno and all,
 
Roman, thanks for reporting this parsing bug with WWW-Authenticate 
HTTP header. I have just fixed it in SVN trunk.
 
Regarding the support for SPNEGO, I've updated the related RFE with a 
link to Bruno's original filter and another one back to this thread. 
I've also changed the target milestone of this RFE to 1.2 as it seems 
there is a good chance we could effectively add support for it.
 
"Support SPNEGO authentication"

http://restlet.tigris.org/issues/show_bug.cgi?id=444

Re: What is missing from Restlet?

[Bruno Harbulot]

Hello,

(OT: does anyone know why the beginning of this thread and a few other 
messages don't seem to have made it to Gmane recently?)



Admittedly, I don't know much about the security implementation in 
Spring, but this looks like the right way to do it. I had started to 
work on something similar (without Spring) after starting this thread 
back in May [1].
The problem is that the I've tried to use the existing Guard and related 
classes to keep it compatible with the 1.1 branch, so the result is a 
bit convoluted. I've also been straight to the features that I needed, 
but haven't finished the more general implementation. Now that 1.1 has 
been released, it might be a better time to do this.
I'd be willing to put this code into the Restlet subversion repository, 
but it should be treated as experimental (and unfortunately, not 
particularly clean). Jerome, any preferred place to put this code? (I'll 
also put the SPNEGO filter that I've been planning to commit for a long 
time.)


Best wishes,

Bruno.

[1] http://restlet.tigris.org/servlets/ReadMsg?list=discuss&msgNo=5328

Karel Vervaeke wrote:

I recently made a stab at spring security integration for Kauri.  There
is not much yet and it's Kauri-specific, but it gives more flexibility
than the existing spring-security integration IMHO.
(http://code.google.com/p/restlet-spring-security/)

Here's how it works in a bird's eye overview:

The spring security filters (ServletFilters) that process authentication
(basic, digest, PKI, ...) are replaced with
"AuthenticationRequestProviders (ARPs)".

An ARP tries to find an authentication attempt in the request.
(e.g. the BasicARP looks at WWW-Authenticate headers, the
BrowserIDBasedARP looks at a BrowserID cookie, ...).

The ARPs are registered with the KauriSpringSecurityFilter (which is a
restlet Filter).  The filter loops over the ARPs until one of them
returns a non-null Authentication object and tries to validate it using
Spring's AuthenticationManager and AccessDecisionManager.

On top of that there is the concept of Realms (to make it possible to
have different URIs map to different security configurations).
We still intend to add the concept of 'authentication strength' which
should make it possible to let an application request a specific
authentication scheme).

I really made a serious attempt to use Restlet's Guards, but in the end,
we thought it better to just write a filter.

Here is an example configuration snippet, it should give a rough idea of
how things are configured:

  

  
  




  




  

  

http://www.kauriproject.org/issues/browser/trunk/core/kauri-runtime/src/main/java/org/kauriproject/runtime/auth/KauriSpringSecurityFilter.java

Regards,
Karel

On Mon, 2008-11-03 at 17:30 +0100, Stephan Koops wrote:

Hi Jerome,

also if we already talked about this: better authentication and an 
authorization. I also want to give input to it, if it is time for that.

best regards
   Stephan


Hi all,

Could you tell me, from your point of view, what are the three most 
important features missing from Restlet ?

__
"Run, Fatboy, Run" sowie "Rails & Ties" kostenlos anschauen!
Blockbuster-Gutscheine sichern unter http://www.blockbuster.web.de

Re: What is missing from Restlet?

[Bruno Harbulot]

Hello,

Bruno Harbulot wrote:
The problem is that the I've tried to use the existing Guard and related 
classes to keep it compatible with the 1.1 branch, so the result is a 
bit convoluted. I've also been straight to the features that I needed, 
but haven't finished the more general implementation. Now that 1.1 has 
been released, it might be a better time to do this.
I'd be willing to put this code into the Restlet subversion repository, 
but it should be treated as experimental (and unfortunately, not 
particularly clean). Jerome, any preferred place to put this code? (I'll 
also put the SPNEGO filter that I've been planning to commit for a long 
time.)


I've just contributed my code under the JCA:
  http://restlet.tigris.org/issues/show_bug.cgi?id=505

It's also available here:
  http://git.kato.mvc.mcc.ac.uk/bruno/altguard.git/

It does need improvements, but hopefully, it will be of interest for the 
discussion on re-factoring the Guard-related classes.


Best wishes,

Bruno.

Re: Well HTTPS

[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 \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\se

Re: Well HTTPS

[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

Re: Well HTTPS

[Bruno Harbulot]

John D. Mitchell wrote:

For what it's worth...

For production use, I've come to the point where I do *NOT* like 
implementing SSL solutions directly in Java.  The extra overhead, 
hassles, etc. just aren't worth it in general.  For example, for both 
Krugle and MarkMail, we have SSL (ala HTTPS) handled directly by the 
load-balancers and everybody behind them is blissfully unaware and this 
makes the management of all of the backend servers much much cleaner, 
easier, faster, etc.


That's a good point. I think the couple of advantages (load-balancing 
excluded) that I find in using an Apache HTTPD front-end are:
 - it's easier to set up out of the box on a Linux machine to run on 
privileged port 443,
 - with this configuration, the private key is only readable by root, 
not by the user running the Java connector.


I can't disagree with you on the complexity of setting up SSL in Java, 
as it was one of the reasons I started jSSLutils; I hope it may have 
improved that sort of configuration a bit (at least it has for me).



Of course, if you're doing really sensitive stuff and need finer 
granularity (medical, financial, etc.) then you're stuck and need to do 
that but in those cases you're already stuck dealing with a lot of 
threats that you can't take for granted anyways so the Java-specific 
hassles aren't such a big issue.


I've experienced problems with mod_jk (only) a couple of times: when 
doing about 200 connections in less than a second, the connections would 
appear in the Apache logs, but nothing happened on the AJP side. I have 
been unable to reproduce this, perhaps the problem was fixed as part of 
an update of the Jetty libs in Restlet.
I wanted to try mod_proxy_ajp. Unfortunately, it doesn't support sending 
the entire chain of client certificates (just the first one) to the Java 
back-end, and I need the whole chain for my application.

The other option would be to remove the Apache HTTPD intermediary.

I also find that Java makes it easier to change the way certificates are 
trusted/validated, especially if they're not standard, or from unusual 
standards (e.g. proxy certificates).



  [But I shall refrain from going off on
my tirade about big complicated SSL installations that then talk to an 
unencrypted database over an unencrypted connection.]  :-)


I think it's OK if you're sure no one can listen on the network in 
between, but it's sometimes hard to check. I shall also refrain from 
talking about SSL support in JDBC drivers :-)



Best wishes,

Bruno.

Re: Guard suggestion

[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 

Noelios Technologies ~ Co-founder ~ 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] 
> 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

Noelios Technologies ~ Co-founder ~ http://www.noelios.com



*De :* [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] ] *De la
part de* Rémi Dewitte
*Envoyé :* vendredi 14 novembre 2008 23:27
*À :* 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]
> 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: Guard suggestion

[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: contributing - areas of interest

[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.name>wrote:
>>> 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=4447&dsMessageId=98
>> 1192
>

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

Re: How to set the SSLContextFactory in the Client

[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();
> Series 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(Series parameters) {
}
});



Best wishes,

Bruno.

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

Re: How to set the SSLContextFactory in the Client

[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();
>> Series 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(Series 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=4447&dsMessageId=1028330

Re: HTTPS trustAnchors error

[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);
> 
> Series 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.(PKIXParameters.java:140)
> at 
> java.security.cert.PKIXBuilderParameters.(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=4447&dsMessageId=1065230
>

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

Re: CSS and HTTPS problem ...

[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=4447&dsMessageId=1499674

Re: Restlet and maven

[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=4447&dsMessageId=1581688

Re: Restlet and maven

[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=4447&dsMessageId=1578606

Re: Grizzly Https Server

[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=4447&dsMessageId=1578563

Re: Restlet 1.1.4 + Jetty + SSL - trustAnchors exception

[Bruno Harbulot]

Hello,

It looks like it's the same problem as here: 
.

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);
> 
> Series 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=4447&dsMessageId=1769928

Re: Restlet 1.2 to become Restlet 2.0

[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 
> 
> Noelios Technologies ~ Co-founder ~ http://www.noelios.com 
> 
> 
>  
> 
>  
>

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

Re: HttpClient Alternatives

[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=dev&msgNo=2531


Best wishes,

Bruno.

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

Dispatching calls to resources internally

[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 
, 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:
   
 /user/123
 ...
   

I'd like to be able to change the user on that order by giving another 
URI, say:
   
 ../user/456
 ...
   

or with the equivalent absolute URI:
   
 http://host.example/user/456
 ...
   

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=4447&dsMessageId=2112197

Re: X509 certificate authentication

[Bruno Harbulot]

Hi,

(I've only just noticed this message.)
webp...@tigris.org wrote:
> Hi All
> 
> I'm prototyping an application which will use user and server certificates 
> extensively: every client request and server response must be ciphered and 
> digitally signed.
> 
> The ciphered part is easy with https, but ¿how do I accomplish the second 
> part?

I'm not sure these two parts are actually so different. If HTTPS is OK 
for encryption (that is, if transport-level encryption is what you 
need), then HTTPS should be OK for signing too (that is, client 
authentication at the TLS level should be sufficient). X.509 
client-certificate authentication already works with Restlet.


> I'm a bit confused and I think of XML-DSIG but then better using a SOAP 
> approach. Is there a more "restful" approach?

Message-level signing is probably more useful if you want to keep those 
messages (and be able to verify their signatures for an audit, for example).
XML signature can be a solution, although it's mostly useful for 
XML-payload if you want to include the signature in the same message.

HTTPSec  could be another solution, although I 
haven't tried it. The specification is open, but the implementation is 
under a fee-based proprietary licence (unless non-commercial use, I 
think, you'd have to check).


Best wishes,

Bruno.

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

Re: Restlet with a large dataset

[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=4447&dsMessageId=2361314
>

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

Re: 2.0m3 and content negotiation

[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=4447&dsMessageId=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

...



* 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=4447&dsMessageId=2361570

Re: 2.0m3 and content negotiation

[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=4447&dsMessageId=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
> 
> ...
> 
> 
> 
> * 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=4447&dsMessageId=2361588