Re: Restlet MVC
Hello, there is only one instance of an Application (this principle also applies to instances of Restlet sub classes) whereas instances of the Resource class are generated at runtime. One instance of Resource is in charge to handle one pair of Request/Response. Generally, the constructor of a Resource is the place where you retrieve the underlying business objects. This helps to know if your Resource is available or not, what is it's current state, etc. Then the acceptRepresentation, removeRepresentations, etc methods are the places to implement business logic. Best regards, Thierry Boileau -- Restlet ~ Core developer ~ http://www.restlet.org http://www.restlet.org/ Noelios Technologies ~ Co-founder ~ http://www.noelios.com http://www.noelios.com/ i am creating a web application using Restlet based on MVC. i have configured ServlerServlet to invoke my Application class, where i have all the URI mappings. i am planning to use the Application class as controller and Resource to implement business logic with other required patterns. can any one suggest me whether this is the correct way to go ahead to implement MVC application in RESTlet? how and when the Application will be loaded? is it for every request or once per application ? Thanks in advance.
Re: Getting the Client address from request
Hm, mod_proxy AFAIK does inserts the 'X-Forwarded-For' HTTP Header, and I am using the ClientInfo.getAddress() so, if I understand correctly, that should work correctly, returning always the _true_ client address? Users are reporting that the Application, when fronted with mod_proxy, is always logging 127.0.0.1 as client address. Will look into this more. What will be returned by this method, if there is no 'X-Forwarded-For' HTTP Header? Thanks, ~t~ On Fri, Nov 21, 2008 at 9:05 AM, Thierry Boileau [EMAIL PROTECTED] wrote: Hello Tamás the ClientInfo.getAddresses() method relies on the content of the X-Forwarded-For HTTP header. Basically, it contains a coma separated list of the IPS of the originating client and the intermediate proxies as follow: X-Forwarded-For: client1, proxy1, proxy2 The first value of this list is the IP of the originating client. This value is also returned by the ClientInfo#getAddress() method. = http://en.wikipedia.org/wiki/X-Forwarded-For Best regards, Thierry Boileau -- Restlet ~ Core developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com Hi there, i am curious, is there any way to get the _real_ client address from Request.getClientInfo()? I am talking about the situation, when you have your Restlet App (whether standalone, or running in Servlet Container) fronted by mod_proxy + httpd... Something like this (example found on the net, in PHP): http://www.zen-cart.com/forum/showpost.php?p=437632postcount=8 The ClientInfo.getAddresses() smells like right place to sniff around, but i don't get the Javadoc and what it really does -- Thanks, ~t~ -- Thanks, ~t~
RE: Well HTTPS
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.
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).
3) In order for Java security to recognise the certificate, it needs to be
added to JRE\lib\security\cacerts, which is the Java certificates file. This
is important when you use a Restlet client to connect to the server via HTTPS
(but it did not seem to be needed by my browser - it needed the IE options
update described in point 2). On my system, 'cacerts' is C:\Program
Files\Java\jre6\lib\security\cacerts. I had some trouble adding my 'serverX'
certificate to it, but the following keytool commands work if you know the
password for cacerts ('changeit' is the default I believe):
keytool -export -alias serverX -file serverX.jks -storetype PKCS12 -keystore
serverX.cer -keypass password
keytool -import -alias serverX -file serverX.jks -noprompt -trustcacerts
-keystore C:\Program Files\Java\jre6\lib\security\cacerts
The first command exports the certificate from PKCS12 format into X.509 (JKS)
format, which is what cacerts needs. In my case, I had to use KeyMan to set
the password for the 'cacerts' file (I set it back to the default of
'changeit'), so when I ran 'keytool -import ...' I could enter the correct
password. There may be a better/easier way to do this.
4) In your Java Restlet server program, in addition to the standard Restlet jar
files, you also need jar files for HTTPS. The only HTTPS connector I could get
to work correctly was 'Simple', which uses these jar files:
lib/com.noelios.restlet.ext.simple_3.1.jar
lib/org.simpleframework_3.1/org.simpleframework.jar
lib/com.noelios.restlet.ext.ssl.jar
lib/org.jsslutils_0.5/org.jsslutils.jar
(Grizzly compiled and ran, but gave inconsistent results - appeared to be
missing requests; Jetty threw an error saying it couldn't register
'AjpServerHelper').
5) Your Restlet server code should then look something like this:
package com.jpc.samples;
import org.restlet.Component;
import org.restlet.Server;
import org.restlet.data.Parameter;
import org.restlet.data.Protocol;
import org.restlet.util.Series;
public class SampleServer {
public static void main(String[] args) throws Exception {
// Create a new Component.
Component component = new Component();
// Add a new HTTPS server listening on port 8183
Server server = component.getServers().add(Protocol.HTTPS, 8183);
SeriesParameter parameters = server.getContext().getParameters();
parameters.add(sslContextFactory,
com.noelios.restlet.ext.ssl.PkixSslContextFactory);
parameters.add(keystorePath, pathserverX.cer);
parameters.add(keystorePassword, password);
parameters.add(keyPassword, password);
parameters.add(keystoreType, PKCS12);
// Attach the sample application.
component.getDefaultHost().attach(, new SampleApplication());
// Start the component.
component.start();
}
}
The HTTP examples all show 'component.getContext().getParameters().add(...) but
this doesn't seem to work
Re: Getting the Client address from request
Sure! Thanks for the tip. That means, that the Application must be aware that it is fronted by mod_proxy? Is there some possibility (or even theoretical chance) to have some kind of fallback mechanism? Will look into restlet sources today... We already have figured out some means to detect mod_proxy and it's misconfiguration, since it was resulting in the most user responses, and almost everyone was having simply misconfigured mod_proxy... You can follow the progress here: https://issues.sonatype.org/browse/NEXUS-959 Thanks ~t~ On Fri, Nov 21, 2008 at 11:23 AM, Thierry Boileau [EMAIL PROTECTED] wrote: Hi Tamas, Oops, I have to complete my previous answer (looks like I forgot something). By default, the ClientInfo.getAddress() is based on this instruction (in HttpClientCall#getLocalAddress): InetAddress.getLocalHost().getHostAddress(). If this instruction fails (host is unknown for example), it returns 127.0.0.1... The ClientInfo#getAddresses() relies on the X-Forwarded-For header *only* if the useForwardedForHeader parameter is set to true (false by default). This is one common parameter of the server connectors ( http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/37-restlet.html). Here is a way to set it to true: Server server = new Server(Protocol.HTTP, 8182, component); component.getServers().add(server); server.getContext().getParameters().add(useForwardedForHeader, true); In this case, the ClientInfo#getAddress() method returns the first IP address listed in the X-Forwarded-For header which should be the IP of the client. I presume that the setting the parameter to true will help you. Could you keep us informed? Best regards, Thierry Boileau -- Restlet ~ Core developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com Hm, mod_proxy AFAIK does inserts the 'X-Forwarded-For' HTTP Header, and I am using the ClientInfo.getAddress() so, if I understand correctly, that should work correctly, returning always the _true_ client address? Users are reporting that the Application, when fronted with mod_proxy, is always logging 127.0.0.1 as client address. Will look into this more. What will be returned by this method, if there is no 'X-Forwarded-For' HTTP Header? Thanks, ~t~ On Fri, Nov 21, 2008 at 9:05 AM, Thierry Boileau [EMAIL PROTECTED] wrote: Hello Tamás the ClientInfo.getAddresses() method relies on the content of the X-Forwarded-For HTTP header. Basically, it contains a coma separated list of the IPS of the originating client and the intermediate proxies as follow: X-Forwarded-For: client1, proxy1, proxy2 The first value of this list is the IP of the originating client. This value is also returned by the ClientInfo#getAddress() method. = http://en.wikipedia.org/wiki/X-Forwarded-For Best regards, Thierry Boileau -- Restlet ~ Core developer ~ http://www.restlet.org Noelios Technologies ~ Co-founder ~ http://www.noelios.com Hi there, i am curious, is there any way to get the _real_ client address from Request.getClientInfo()? I am talking about the situation, when you have your Restlet App (whether standalone, or running in Servlet Container) fronted by mod_proxy + httpd... Something like this (example found on the net, in PHP): http://www.zen-cart.com/forum/showpost.php?p=437632postcount=8 The ClientInfo.getAddresses() smells like right place to sniff around, but i don't get the Javadoc and what it really does -- Thanks, ~t~ -- Thanks, ~t~ -- Thanks, ~t~
Re: Getting the Client address from request
Hi Tamas, Oops, I have to complete my previous answer (looks like I forgot something). By default, the ClientInfo.getAddress() is based on this instruction (in HttpClientCall#getLocalAddress): InetAddress.getLocalHost().getHostAddress(). If this instruction fails (host is unknown for example), it returns 127.0.0.1... The ClientInfo#getAddresses() relies on the X-Forwarded-For header *only* if the useForwardedForHeader parameter is set to true (false by default). This is one common parameter of the server connectors (http://wiki.restlet.org/docs_1.1/13-restlet/27-restlet/37-restlet.html). Here is a way to set it to true: Server server = new Server(Protocol.HTTP, 8182, component); component.getServers().add(server); server.getContext().getParameters().add(useForwardedForHeader, true); In this case, the ClientInfo#getAddress() method returns the first IP address listed in the X-Forwarded-For header which should be the IP of the client. I presume that the setting the parameter to true will help you. Could you keep us informed? Best regards, Thierry Boileau -- Restlet ~ Core developer ~ http://www.restlet.org http://www.restlet.org/ Noelios Technologies ~ Co-founder ~ http://www.noelios.com http://www.noelios.com/ Hm, mod_proxy AFAIK does inserts the 'X-Forwarded-For' HTTP Header, and I am using the ClientInfo.getAddress() so, if I understand correctly, that should work correctly, returning always the _true_ client address? Users are reporting that the Application, when fronted with mod_proxy, is always logging 127.0.0.1 http://127.0.0.1 as client address. Will look into this more. What will be returned by this method, if there is no 'X-Forwarded-For' HTTP Header? Thanks, ~t~ On Fri, Nov 21, 2008 at 9:05 AM, Thierry Boileau [EMAIL PROTECTED] mailto:[EMAIL PROTECTED] wrote: Hello Tamás the ClientInfo.getAddresses() method relies on the content of the X-Forwarded-For HTTP header. Basically, it contains a coma separated list of the IPS of the originating client and the intermediate proxies as follow: X-Forwarded-For: client1, proxy1, proxy2 The first value of this list is the IP of the originating client. This value is also returned by the ClientInfo#getAddress() method. = http://en.wikipedia.org/wiki/X-Forwarded-For Best regards, Thierry Boileau -- Restlet ~ Core developer ~ http://www.restlet.org http://www.restlet.org/ Noelios Technologies ~ Co-founder ~ http://www.noelios.com http://www.noelios.com/ Hi there, i am curious, is there any way to get the _real_ client address from Request.getClientInfo()? I am talking about the situation, when you have your Restlet App (whether standalone, or running in Servlet Container) fronted by mod_proxy + httpd... Something like this (example found on the net, in PHP): http://www.zen-cart.com/forum/showpost.php?p=437632postcount=8 http://www.zen-cart.com/forum/showpost.php?p=437632postcount=8 The ClientInfo.getAddresses() smells like right place to sniff around, but i don't get the Javadoc and what it really does -- Thanks, ~t~ -- Thanks, ~t~
Re: removeRepresentations and setAvailable
Thanks, Thierry. I hadn't considered this from an idempotence point of view, but that makes sense. Regards Richard Thierry Boileau wrote: Hello Richard, after having a look at the HTTP specification (http://www.w3.org/Protocols/rfc2616/rfc2616-sec9.html#sec9.7), a successfull delete operation is denoted by a successful status (200, 202 or 204) but at the same time the 404 status expresses the fact that the underlying resource is here or not. On one hand we can argue that the effects of two DELETE requests are the same, thus they can return the same status (in this case the end status is considered as important). On the other hand, we want to insist on the fact that the state of the resource has changed and thus return a successful status at the first delete and a 404 for the others. I'm not sure what is the right answer. It may depend on your requirements. Best regards, Thierry Boileau -- Restlet ~ Core developer ~ http://www.restlet.org http://www.restlet.org/ Noelios Technologies ~ Co-founder ~ http://www.noelios.com http://www.noelios.com/ Hi I'm testing my system to see how it handles a DELETE request to a non-existent resource. I'm expecting a 404 response. Although I'm flagging my resource as unavailable in the constructor/init method removeRepresentations still gets invoked, which means I have to explicitly handle the 404 response. Is this the correct behaviour? Regards Richard Hoberman
Re: Restlet MVC
This is a purely theoretical observation and not really meant as an answer, but I did want to sort of get it on the record here. The MVC paradigm is a specific separation of concerns architecture which has gained wide conceptual support because it has long been generally considered best practice for GUI applications. Overlaying MVC onto the internals of a RESTful web application may encourage correct separation of concerns, but also may not. MVC alone does not capture separations of concern at multiple layers of an n-tier application. REST works very well with a rich client (GWT, Flex RIA, SWT, Swing...) that has its own complex UI, ideally implemented using the MVC pattern. As Thierry says, the internals of a Restlet application can be composed using an MVC way of thinking. Here, though, the MVC pattern is not an automatic best practice and you may do better to just study the concerns in your server and leveraging the concepts in Restlet (which in turn are REST concepts) without reference to MVC. Fielding mentions MVC in passing in his REST dissertation, when surveying preexisting peer-to-peer architectures, but REST itself is not based on an MVC way of thinking. I would argue that there is not a correct way of implementing MVC in Restlet ... it's just that if you choose to think about server-side things this way, there are ways (as Thierry outlines) of accomplishing this. Personally, I would set aside thinking about MVC on the server, in favor of thinking purely about REST. I tend to find the MVC switch in my brain only activates when writing client side code, where it is ideally suited. You may get widely divergent opinions on the list, but that is mine! :-) - Rob On Fri, Nov 21, 2008 at 2:09 AM, Gan123 [EMAIL PROTECTED] wrote: i am creating a web application using Restlet based on MVC. i have configured ServlerServlet to invoke my Application class, where i have all the URI mappings. i am planning to use the Application class as controller and Resource to implement business logic with other required patterns. can any one suggest me whether this is the correct way to go ahead to implement MVC application in RESTlet? how and when the Application will be loaded? is it for every request or once per application ? Thanks in advance. -- View this message in context: http://n2.nabble.com/Restlet-MVC-tp1560691p1560691.html Sent from the Restlet Discuss mailing list archive at Nabble.com.
Re: Restlet MVC
Bravo, Rob! I agree 100%! FYI, the FAQ has an entry on MVC: http://www.restlet.org/documentation/1.1/faq#10 Not sure who wrote the answer, but if you do decide to follow MVC, I think the approach presented in the answer makes a lot of sense. Avi -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
Re: Restlet MVC
Maybe the first line of that FAQ answer should be modified to avoid the word implementation, e.g., There is a rough correspondence between the MVC pattern [cite?] and the Restlet framework: --tim On Fri, Nov 21, 2008 at 9:18 AM, Avi Flax [EMAIL PROTECTED] wrote: Bravo, Rob! I agree 100%! FYI, the FAQ has an entry on MVC: http://www.restlet.org/documentation/1.1/faq#10 Not sure who wrote the answer, but if you do decide to follow MVC, I think the approach presented in the answer makes a lot of sense. Avi -- Avi Flax » Lead Technologist » Partner » Arc90 » http://arc90.com
Re: Well HTTPS
Hi,
Ben Johnson wrote:
Hi
I am new to Restlet and web programming, HTTP and SSL certificates in
general, but hopefully my recent experiences will help. I spent the
last several days trying to find a Restlet example using HTTPS (there
isn't one), and eventually pieced together the following (using Windows
XP SP2 with Java 6, Eclipse, Restlet 1.1.1):
1) Create your keys and certificate. I tried both 'keytool' and IBM's
KeyMan to do this (KeyMan is easier, but more work to obtain, as you
need to register, etc...). Using keytool from a command prompt you need
to enter two commands - the first one creates the keystore file with the
keys, the second certifies it (self-certification, ok for testing). The
most important thing is that the name of the machine you will be using
the certificate on matches what you specify (in the example below, my
machine is called 'serverX'):
keytool -genkey -dname CN=serverX, OU=IT, O=JPC, C=GB -alias serverX
-keypass password -keystore serverX.cer -storepass password -keyalg
RSA -storetype PKCS12 -provider sun.security.provider.Sun
keytool -selfcert -alias serverX -keystore serverX.cer -storepass
password -storetype PKCS12
The keystore file has now been created and self-certified: in this
example it is called 'serverX.cer' and was saved in the current
directory. There are two passwords: one for the keys and one to access
the keystore. I set them both to 'password' for testing. The name of
the keystore file ('serverX.cer') is not important, I just used that for
consistency.
Usually, the extension for JKS keystores is jks and the extension for
PKCS#12 keystores is p12. cer tends to be used for X.509
certificates in DER format (application/x-x509-ca-cert), which are files
containing just the certificate: this is the format produced by keytool
-export.
It looks from the example below that you've used jks for that, whereas
it's not actually a JKS file but a cer file.
2) To prevent warnings in a browser, add the keystore to the 'Trusted
Root Certification Authorities' on your computer. In Windows XP, I just
used Internet Options (via IE7 or Control Panel - Internet Options). On
the 'Content' tab, click 'Certificates', then go to 'Trusted Root
Certification Authorities' tab, click 'Import...' and follow the steps
to import your keystore file (in my example, 'serverX.cer'). It will
give warnings about not being verified, which is ok for testing (but
it must be properly signed for production).
Since your .cer is in fact a .p12, this might import the private key as
well (that's what you would do if you wanted to use client-certificate
authentication). In fact, the actual .cer exported by keytool should be
sufficient. Just to clarify the extensions:
keytool -export -alias serverX -file serverX.cer -storetype PKCS12
-keystore serverX.p12 -keypass password
(Shouldn't this be -storepass rather than -keypass by the way?)
3) In order for Java security to recognise the certificate, it needs to
be added to JRE\lib\security\cacerts, which is the Java certificates
file. This is important when you use a Restlet client to connect to the
server via HTTPS (but it did not seem to be needed by my browser - it
needed the IE options update described in point 2). On my
system, 'cacerts' is C:\Program Files\Java\jre6\lib\security\cacerts.
I had some trouble adding my 'serverX' certificate to it, but the
following keytool commands work if you know the password for cacerts
('changeit' is the default I believe):
keytool -export -alias serverX -file serverX.jks -storetype PKCS12
-keystore serverX.cer -keypass password
keytool -import -alias serverX -file serverX.jks -noprompt -trustcacerts
-keystore C:\Program Files\Java\jre6\lib\security\cacerts
The first command exports the certificate from PKCS12 format into X.509
(JKS) format, which is what cacerts needs. In my case, I had to use
KeyMan to set the password for the 'cacerts' file (I set it back to the
default of 'changeit'), so when I ran 'keytool -import ...' I could
enter the correct password. There may be a better/easier way to do this.
If for some reason, you can write to that file (which is likely to be
shared by all users on that system), you can specify your own truststore
using -Djavax.net.ssl.trustStore=mytruststore.jks
-Djavax.net.ssl.trustStore=JKS
-Djavax.net.ssl.trustStorePassword=ABCDEFGH as JVM parameters.
If you're requiring client-authentication (in which case it makes sense
to set up a trust store on the server), you can used the truststorePath,
truststorePassword and truststoreType parameters of the Restlet Server
when you're using the sslContextFactory (as you've done below).
There's currently no SSLContextFactory support in the client connectors
of Restlet, so you'll have either to modify the central cacerts as you
did, or use the SSL system properties.
As a side note, the C:\Program Files\Java\jre6\lib\security\cacerts is
the set
how to Redirect...
Hi, Just started exploring restlet and trying to implement a simple employee details info management app. it have two pages, one to create a new employee. second that lists all employees. once the employee is created the resource should be redirected to other resource which will list all the employees. how i could do this either by giving URI or by giving second resource ref in 1st resource? Thanks in advance. -- View this message in context: http://n2.nabble.com/how-to-Redirect...-tp1562040p1562040.html Sent from the Restlet Discuss mailing list archive at Nabble.com.
Re: Well HTTPS
Hi, I'm not sure you're clear on what certificates, signing and encryption are. Roughly speaking, an X.509 certificate is the combination of a public key and some information (subject distinguished name, date from/to, other attributes) that has been signed using a private key usually corresponding to another certificate. The signer (CA) asserts authority on the validity of the information in this certificate by signing it, but the certificate itself is not enciphered and it's meant to be public. The certificate of the signer (corresponding to its private key) may be an intermediate CA or a root CA certificate. In the latter case, it's a self-signed certificate (which means that it's been signed with its own private key). Why would you trust such a CA certificate? That's a leap of faith. Browsers and operating systems come with a bundle of CA certificates they trust by default (Verisign, Thawte, ...), but you could have your own PKI and set your own within your organisation. As Ben pointed out in another message on this thread, the default set of trusted CA certificates in the JVM is in a file called cacerts. It's however up to you to make sure you want to trust the CA certificates it contains. Similarly IE, Firefox, OSX Keychain come with their set of trusted CAs. The only reasons you'd trust them are: - you trust the copy of the software you've obtained is genuine, and - you trust the company/organisation that produced that software to have made the right choices, because it has bundled the CA certificates it wanted you to have. Best wishes, Bruno. Mohammed Al-Adawi wrote: Hi Given X = Public key and some data; Trusted Certificate is X which is digitally signed by CA private key. Digitally signed means hashing X and then encrypt it with CA private key. if that is true CA public key must be some where and NOT encrypted so you can decrypt certificate, You can say that I have an emotional problem coming from the fact: NO ONE said that CA public key is there available, also no one said where it is stored!! keystore, truststore, or it is not encrypted nor hashed. Can you solve my emotional problem?? Thanks
Re: Well HTTPS
Thanks for the feedback Bruno; I'm still learning about certificates and
Restlet, and I appreciate your clarifications!
Regards
Ben
--
From: Bruno Harbulot [EMAIL PROTECTED]
Sent: Friday, November 21, 2008 2:54 PM
To: discuss@restlet.tigris.org
Subject: Re: Well HTTPS
Hi,
Ben Johnson wrote:
Hi
I am new to Restlet and web programming, HTTP and SSL certificates in
general, but hopefully my recent experiences will help. I spent the last
several days trying to find a Restlet example using HTTPS (there isn't
one), and eventually pieced together the following (using Windows XP SP2
with Java 6, Eclipse, Restlet 1.1.1):
1) Create your keys and certificate. I tried both 'keytool' and IBM's
KeyMan to do this (KeyMan is easier, but more work to obtain, as you need
to register, etc...). Using keytool from a command prompt you need to
enter two commands - the first one creates the keystore file with the
keys, the second certifies it (self-certification, ok for testing). The
most important thing is that the name of the machine you will be using
the certificate on matches what you specify (in the example below, my
machine is called 'serverX'):
keytool -genkey -dname CN=serverX, OU=IT, O=JPC, C=GB -alias
serverX -keypass password -keystore serverX.cer -storepass
password -keyalg RSA -storetype PKCS12 -provider
sun.security.provider.Sun
keytool -selfcert -alias serverX -keystore serverX.cer -storepass
password -storetype PKCS12
The keystore file has now been created and self-certified: in this
example it is called 'serverX.cer' and was saved in the current
directory. There are two passwords: one for the keys and one to access
the keystore. I set them both to 'password' for testing. The name of
the keystore file ('serverX.cer') is not important, I just used that for
consistency.
Usually, the extension for JKS keystores is jks and the extension for
PKCS#12 keystores is p12. cer tends to be used for X.509 certificates
in DER format (application/x-x509-ca-cert), which are files containing
just the certificate: this is the format produced by keytool -export.
It looks from the example below that you've used jks for that, whereas
it's not actually a JKS file but a cer file.
2) To prevent warnings in a browser, add the keystore to the 'Trusted
Root Certification Authorities' on your computer. In Windows XP, I just
used Internet Options (via IE7 or Control Panel - Internet Options). On
the 'Content' tab, click 'Certificates', then go to 'Trusted Root
Certification Authorities' tab, click 'Import...' and follow the steps to
import your keystore file (in my example, 'serverX.cer'). It will give
warnings about not being verified, which is ok for testing (but it must
be properly signed for production).
Since your .cer is in fact a .p12, this might import the private key as
well (that's what you would do if you wanted to use client-certificate
authentication). In fact, the actual .cer exported by keytool should be
sufficient. Just to clarify the extensions:
keytool -export -alias serverX -file serverX.cer -storetype
PKCS12 -keystore serverX.p12 -keypass password
(Shouldn't this be -storepass rather than -keypass by the way?)
3) In order for Java security to recognise the certificate, it needs to
be added to JRE\lib\security\cacerts, which is the Java certificates
file. This is important when you use a Restlet client to connect to the
server via HTTPS (but it did not seem to be needed by my browser - it
needed the IE options update described in point 2). On my system,
'cacerts' is C:\Program Files\Java\jre6\lib\security\cacerts. I had
some trouble adding my 'serverX' certificate to it, but the following
keytool commands work if you know the password for cacerts ('changeit' is
the default I believe):
keytool -export -alias serverX -file serverX.jks -storetype
PKCS12 -keystore serverX.cer -keypass password
keytool -import -alias serverX -file
serverX.jks -noprompt -trustcacerts -keystore C:\Program
Files\Java\jre6\lib\security\cacerts
The first command exports the certificate from PKCS12 format into X.509
(JKS) format, which is what cacerts needs. In my case, I had to use
KeyMan to set the password for the 'cacerts' file (I set it back to the
default of 'changeit'), so when I ran 'keytool -import ...' I could enter
the correct password. There may be a better/easier way to do this.
If for some reason, you can write to that file (which is likely to be
shared by all users on that system), you can specify your own truststore
using -Djavax.net.ssl.trustStore=mytruststore.jks -Djavax.net.ssl.trustStore=JKS
-Djavax.net.ssl.trustStorePassword=ABCDEFGH as JVM parameters.
If you're requiring client-authentication (in which case it makes sense to
set up a trust store on the server), you can used the truststorePath,
truststorePassword and truststoreType parameters of the Restlet Server
when you're
Re: Getting the Client address from request
On Friday 2008.11.21, at 02:35 , Tamás Cservenák wrote: [...] Thanks for the tip. That means, that the Application must be aware that it is fronted by mod_proxy? Is there some possibility (or even theoretical chance) to have some kind of fallback mechanism? Will look into restlet sources today... Well, yes and no. I don't know of any guaranteed, general way to know that it's a proxy and not an original client -- that's a large rabbit hole. One hack would be to change the getAddresses() code can do the underlying call to InetAddress.getLocalHost().getHostAddress() and only if it fails or returns localhost then try the extraction of X- Forwarded-For: and only if that fails too then return localhost. This handles the dominant case, such as yours, where there's a fronting proxy on the local machine. However, I think this entire approach of having getAddresses() hide the reality of X-Forwarded-For: from the applications is actually a bad idea. Different applications and/or in different deployment environments do really need to understand the difference between the upstream client, whether or not an X-Forwarded-For: exists or not, and can decide for itself whether or not it needs the information out of X- Forwarded-For: header (and how much to trust that information). So, I'd move the X-Forwarded-For: stuff out of getAddresses() and into a getForwardedAddresses(). Then all applications can do what's correct for them. Take care, John
Re: Restlet MVC
On Fri, Nov 21, 2008 at 09:44, Tim Peierls [EMAIL PROTECTED] wrote: Maybe the first line of that FAQ answer should be modified to avoid the word implementation, e.g., There is a rough correspondence between the MVC pattern [cite?] and the Restlet framework: I think we can just change the word implementing to following. But I like the sentence you've proposed; I think we could just add that to the answer, as the first sentence, like so: There is only a rough correspondence between the a href=http://en.wikipedia.org/wiki/Model-view-controller;MVC pattern/a and the Restlet framework; some a href=http://n2.nabble.com/Restlet-MVC-tp1560691p1561792.html;debate/a exists as to whether it should be employed at all. For those who wish to follow the MVC pattern with Restlet, here is the basic proposition: How's that? Jerome, maybe it's time to move the FAQ to the Wiki so it can be more readily edited!
Re: Well HTTPS
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. 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. [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.] :-) Hope this helps, John
Usurping Directory
I would like to modify the standard Directory to return something different than the file when a file is encountered. For example, peruse a directory structure (default behavior), but when you get to the bottom (an actual file), then return a report based on that file, instead of the file itself. It appears that I need a custom DirectoryResource which is attached to a Directory via #setTargetClass. I have the following questions: 1. Setting the target class doesn't seem to be invoking the resource 2. I'm not sure what I would need to override to have custom behavior: #getVariants? 3. Is there a better way to approach the problem? Thanks in advance, Cliff
RE: Usurping Directory
As an upgrade (Restlet request!), looking through the source code it seems that the simplest thing would be if I could insert my own ReferenceList implementation. Perhaps you could have a #setReferenceList option which would take my own (sub-)class. Not only could I change the HREF, but it would be great to put in my own HTML representation anyway, with style, logo, etc. Cliff _ From: Cliff Binstock [mailto:[EMAIL PROTECTED] Sent: Friday, November 21, 2008 2:54 PM To: discuss@restlet.tigris.org Subject: Usurping Directory I would like to modify the standard Directory to return something different than the file when a file is encountered. For example, peruse a directory structure (default behavior), but when you get to the bottom (an actual file), then return a report based on that file, instead of the file itself. It appears that I need a custom DirectoryResource which is attached to a Directory via #setTargetClass. I have the following questions: 1. Setting the target class doesn't seem to be invoking the resource 2. I'm not sure what I would need to override to have custom behavior: #getVariants? 3. Is there a better way to approach the problem? Thanks in advance, Cliff
TCP RST attack detected on file upload cut
Hello, I'm observing an odd situation where restlet is involved: pull the net cable during file upload and router (hardware box, not Router.class) detects TCP RST attack and blacklist our server for access from subnet. This is the topology: - office subnet: client application - office router: NAT - remove server: Apache HTTPS proxying to localhost - remove server: Restlet with default HTTP connector The behavior can be consistently reproduced with our setup and access to remote server is temporarily blocked to entire office subnet. The client application makes a GET and then a POST w/ a big file, so that I have time to pull the plug, and that's it. I tried reading a bit about TCP RST attack but so far I do not know how to avoid this problem, except for disabling the attack detection in the router or telling people not to pull the plug during upload. If anybody has some insights to share, I appreciate. Thanks, Diego -- Diego Ballve Digital Artefacts Europe http://www.digital-artefacts.fi/
