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: SSL + Virtual Hosts and Issue #489?

[Alex Milowski]

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.

> 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.

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

> 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.

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

--Alex Milowski

Re: Delivering files via Directory from a folder within the webapp context

[Aron Roberts]

In the message "  Re: Delivering files via Directory from a folder 
within t", dated 2008-07-03, Thierry Boileau wrote:


... the snapshot delivered tomorrow ([1]) ... will also contains 
some other changes :
- the ability to add a component via an XML configuration file (see 
[http://www.restlet.org/documentation/1.1/api/org/restlet/Component.html]) 
called "restlet.xml" and located under the "WEB-INF" directory.
- the ability to take automatically into account the context path of 
the Servlet application, that is to say, a new parameter lets the 
system add automatically  (or not) the context path at the beginning 
of the uri pattern of all "attach" instructions.


  This is exciting news!  Two questions:

  1. We're looking for the ability to allow contributors to our
 projects to 'drop in' a folder containing their own resource
 and business object classes, and allow us to integrate
 their "drop-ins" through external configuration alone,
 with no other code changes required.

 How far does this new feature take us towards that goal?

 (The specific use case is a calendar event data application,
 where contributors could add support for accessing new
 types of repositories of calendar events; e.g. Exchange and
 SharePoint servers, Dean Evans & Associates EMS repositories,
 and so on, to the core repositories we've already defined.)

  2. Does this also work with the Simple framework and built-in
 Restlet server connectors?

 (To the best of my recollection, Simple, at least,
 doesn't require a WEB-INF directory.)

Aron

Hanging on ServerSocket.accept()

[Paul J. Lucas]

When launching my application, perhaps 1/10 times, the underlying web  
server gets stuck in ServerSocket.accept().  This happens only when  
run under Windows and only for one of our users.  (The user had turned  
off all firewall and virus software.)  The thing that concerns me is  
how wide-spread the problem is.  (Our product is not yet released.)   
The problem has never been observed to happen under Mac OS X.


We have been using the Simple web server.  I tried replacing it with  
Jetty, but the same thing happens.


Has anybody else experienced something like this or have any  
suggestions?


- Paul

Re: Delivering files via Directory from a folder within the webapp context

[Thierry Boileau]

Hello Christian,

by default, no WAR client connector was available, and it was quite 
difficult to add such behaviour.
We've decided to change this and to add automatically a WAR client on 
the Component (the default one, or the one you provide yourself). This 
fix is available in the svn repository and will be available in the 
snapshot delivered  tomorrow ([1]).


This delivery will also contains some other changes :
- the ability to add a component via an XML configuration file (see 
[2]) called "restlet.xml" and located under the "WEB-INF" directory.
- the ability to take automatically into account the context path of 
the Servlet application, that is to say, a new parameter lets the system 
add automatically  (or not) the context path at the beginning of the uri 
pattern of all "attach" instructions.


best regards,
Thierry Boileau
[1] http://www.restlet.org/downloads
[2] http://www.restlet.org/documentation/1.1/api/org/restlet/Component.html


Hi,

I would like to publish files from a special folder within my web applications 
WAR file. After installing the Restlet web application within Tomcat this 
folder gets expanded to "/{context-path}/meta". It contains some XML files 
describing the RESTful web service like WADL files, XML schema files and so on.


What is the recommended way of achieving this using Restlet 1.1 M4? I think I 
should use a Directory component but it seems the required LocalReference does 
support absolute file names only. Using a WAR URL wasn't not successful; but I 
found some message "WARNUNG: No available client connector supports the 
required protocols: 'WAR' . Please add the JAR of a matching connector to your 
classpath." in the log file, so there might be missing something I don't know.


Thanks

Christian


  

Delivering files via Directory from a folder within the webapp context

[Christian Möller]

Hi,

I would like to publish files from a special folder within my web applications 
WAR file. After installing the Restlet web application within Tomcat this 
folder gets expanded to "/{context-path}/meta". It contains some XML files 
describing the RESTful web service like WADL files, XML schema files and so on.

What is the recommended way of achieving this using Restlet 1.1 M4? I think I 
should use a Directory component but it seems the required LocalReference does 
support absolute file names only. Using a WAR URL wasn't not successful; but I 
found some message "WARNUNG: No available client connector supports the 
required protocols: 'WAR' . Please add the JAR of a matching connector to your 
classpath." in the log file, so there might be missing something I don't know.

Thanks

Christian

Re: Spring Security Integration

[Evgeny Shepelyuk]

Hi Jerome


Hi Evgeny,

Regarding the Google Code project, this is fine if you want to maintain  
it as a standalone project.


However, if your plan is to contribute source code back to the Restlet  
project, then we will likely run into copyright/license issues (see  
http://www.restlet.org/community/contribute). If this is your goal, I  
suggest that you reconsider the need for an external code repository.


I'm not planning to maintain it separately of restlet project and hope  
once this code will be included into restlet sources :)
Idea of creating Google Code project is having free version control system  
to track changes and provide convenient way of accesing
and browsing current sources. So it's just temporary solution comfortable  
to me


As we already did in the past, granting SVN access to external  
committers for extensions code if perfectly possible if there is an  
ongoing contribution. See more details here:  
http://wiki.restlet.org/docs_1.1/g1/13-restlet/50-restlet/51-restlet.html




That pages has good information. Thnx !

Regarding authentication, there are other mechanisms than login/password  
verification, for example certificate verification, that suggest that  
overriding Guard at the authenticate() level is going to be more  
flexible.



Ok thnx. I will put modifications recently.


Best regards,
Jerome


--
Best Regards
Evgeny K. Shepelyuk

Re: Unwanted removal of attribute suffix in Tomcat environment

[Thierry Boileau]

Hi Lutz,

when requesting manually (i.e. by typing the URI in my browser) the 
three URIs in any order, it should works correctly (I mean it works for me).

Can you confirm this?
However, I've noticed the following thing.
When clicking on the "back" link of the third page, I go back to 
"http://myserver/myapp/test/foo/"; instead of 
"http://myserver/myapp/test/"; (because of the ending "/"). You can note 
that the "base" URI is not the same, it ends with "/test/foo/" instead 
of "/test/". Then, when clicking on any link, the requested URI is  
"http://myserver/myapp/test/foo/foo/bar.html";. When applying the 
template "/foo/{filename}", the value of the "filename" variable is 
"foo". I hope this is the cause of the problem.


best regards,
Thierry Boileau



Hello Thierry,

thanks a lot for responding so quickly and for your help - I greatly 
appreciate it!


Apparently, you were at least partly right about the libraries - changing 
them to the newer version 1.1 (Test) has changed the behavior - but it is 
still not the way it should be...


I have prepared a very small WAR file to illustrate the problem - if you 
are willing to download it, it should help to clarify the problem (< 500 kB,

Source code and libraries included): http://www.leonidat.de/test.war

Having updated the libraries at first seemed to do the trick - the endings 
were accessible. However, once you send a request such as

 "http://myserver/maypp/test/foo/bar.html/"; (with a "/" at the end), the old
problem is back again. You never get a suffix after one such request with a
trailing "/" until you restart the server or redeploy the application.

To illustrate that, I have prepared three examples in the WAR, just deploy it 
in your tomcat, navigate to "http://localhost:8080/test/"; and try the three 
links I have provided. Examples 1 and 2 will work fine. After clicking the 
third link, the other two will have changed their behavior...


Any idea how to avoid that strange behavior? Obviously, I would not like to
rely on the hope that nobody will ever send a "wrong" request to the 
service...


Thanks a great deal for your support!

Cheers,
Lutz 



  

Re: Issue in FileClientHelper

[Thierry Boileau]

Hi Rémi,

thanks for your report, it helps fixing a bug in the FileClientHelper. 
The fix is now available in the svn repositories (Restlet 1.0 and 1.1).

Could you try again and tell us if it solves your problem?

best regards,
Thierry Boileau


Yes I have the TunnelService on but off for extensions. The 
FileClientHelper search for a file with file starting with the same 
baseName and having the same set of extensions : no surprise it finds 
test2.xml.
I'll be off for the end of the week. I will test it as soon as 
possible and investigate a bit more on this.

Thanks for the fast feedback !
Rémi


On Wed, Jul 2, 2008 at 6:09 PM, Thierry Boileau <[EMAIL PROTECTED] 
> wrote:


Hello Rémi,

I'm not able to reproduce your problem with Restlet 1.1M4. I send
you my sample code.
It contains a directory and 2 restlet, one that creates/updates
the "test.xml" file, the other the "test2.xml" file.
Just hot http://localhost:8182/restletPut1 and
http://localhost:8182/restletPut2 to "invoke" them.

Are you using some filter? such as TunnelFilter?

best regards,
Thierry Boileau

Hello,
I have an issue with the implementation of PUT on files.
Let say I have files in a directory :
test.xml
test2.xml
If I make a PUT on test.xml it will modify test2.xml which is
not exactilly what I would expect.
I don't really catch what I don't understand reading from line
187 to line 219 in FileClientHelper.
If it is not a bug what should I do ?

I am using this line of code :
Response resp =

Application.getCurrent().getContext().getClientDispatcher().put(resourceUri,new
DomRepresentation(MediaType.TEXT_XML,doc));

I am using Restlet 1.1M4.

Thanks a lot,
Rémi

RE: SSL + Virtual Hosts and Issue #489?

[Jerome Louvel]

Hi Bruno,

Thanks for the extra details, I've updated the RFE with the last part of
your reply:

"SSL connector configuration improvements"
http://restlet.tigris.org/issues/show_bug.cgi?id=489 

What you propose sounds great to me. I don't think either that Jetty 7
should be part of Restlet 1.1, more likely part of Restlet 1.2.

Best regards,
Jerome


-Message d'origine-
De : news [mailto:[EMAIL PROTECTED] De la part de Bruno Harbulot
Envoyé : mercredi 2 juillet 2008 16:45
À : discuss@restlet.tigris.org
Objet : Re: SSL + Virtual Hosts and Issue #489?

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: Delivering static files from Restlet-Servlet

[Thierry Boileau]

Hi Christian,


what's your way of anticipating I'm working with Eclipse? :-)

Well, I don't anticipate. I work with Eclipse and as usual just export the 
project as a JAR file with the source files. ;)

best regards,
Thierry Boileau



Hi Christian,

I send you a complete Eclipse project which works on my environment. It 
contains 2 applications with both Resource and Directory.

The problem is located in this part of the code :

getDefaultHost().attach("/meta", new MyApplication(getContext()));

When attaching your application, you need to add the context path (i.e. 
what you mentionned as the {root-of-webapp}) :


getDefaultHost().attach("/{root-of-webapp}/meta", new MyApplication(getContext


()));
  

We are currently working on this point which need to be properly addressed.

Best regards,
Thierry Boileau



Hi Thierry,

great, it works now!

Thank you very much for sparing no effort to help me by sending some kind of 
"personal" Restlet application - btw, what's your way of anticipating I'm 
working with Eclipse? :-)


Thanks again and best regards.

Christian