Re: create inbound root override problem
If your method name is indeed createInboudRoot(), then you only have made a small typo: there is a n missing in the word inbound. ;) -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/create-inbound-root-override-problem-tp4956547p4961436.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2595701
Restlet and DAO
Hi I have a question about how to inject my DAO. I looked around a bit (probably not long enough), and my guess at this point would be that I implement a filter which places the DAO in the attributes of the Request object. Is this the correct modus operandi? What about security? I'm not very keen on putting the DAO in a map where 'everybody' kan retrieve it. kind regards, Nico -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Restlet-and-DAO-tp4962381p4962381.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2595900
Re: Restlet and DAO
Hi Nico, How about injecting your DAO on a BaseResource class and extending this in every resource? -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Restlet-and-DAO-tp4962381p4962395.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2595901
Re: Restlet and DAO
Yes, I had thought about that, but a filter has a beforeHandle() and a afterHandle() method, so I can easily set up a transaction before the handling and easily perform a commit or a rollback in after the handling. If I would use a BaseResource I would need to add these calls for each extending class, or are there provisions for such a use? Although thinking it through again at this moment, I probably need to overwrite the handle() method in ServerResource to obtain this behaviour? Thanks, Nico -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Restlet-and-DAO-tp4962381p4962438.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2595911
Re: SSL modifications since 2.0 RC 1 ?
Hi Nicolas, Nicolas Rinaudo wrote: Hey, We've just upgraded form RC 1 to RC 3 (we skipped RC 2 due to blocking issues), and there appears to have been some changes in the way SSL keystores are managed - our test self-signed certificate that worked perfectly with RC 1 now has issues with RC 3. The behaviour is a bit odd: - Firefox accepts it after having been told to ignore it. - Safari refuses it, whether or not it has been told to ignore it. Could you clarify what you mean by accept/ignore? I'm not sure what this means in the context of Firefox/Safari. In Firefox, all I tend to see is 'Get me out of here!', 'I understand the risks' - 'Add exception' (and perhaps 'Permanently store this exception'). (Is it Safari on Mac or Windows, btw?) - curl accepts it with the -k flag That should always work indeed, since it doesn't verify the certificate of the server at all. - connecting using an RC 1 powered Java client works, an RC 3 powered one fails. Are you using client-certificates? Could you explain what configuration you use for the client? (In particular w.r.t the trust store?) From what I've found, it appears that there were some modifications in keystore management, but the only thing I could find was SSL keystores configuration was adjusted for simplicity purpose in the RC 2 release notes. Is there a list of what precisely these changes are I can find somewhere ? I don't know whether that's useful, but: - we're using the Simple web server. - querying our server with curl, the only differences I could find between RC 1 and RC 3 were: SSL connection using EDH-RSA-DES-CBC3-SHA (RC 1) and SSL connection using DHE-RSA-AES256-SHA (RC 3). One of the changes that was made was that the Simple connector was using the keystore for both the keystore and the truststore. Now, the truststore is the default JRE truststore unless explicitly specified (which is more correct), like it was the case for the other connectors (Jetty, Grizzly). The keystore is what has the private key and the certificate that are local (server cert+priv. key on the server and client cert+priv. key on the client). The truststore is the repository of trust anchors used to evaluate trust in the remote certificate (for example, you would have to put your server's self-signed cert into the client's truststore for it to be trusted by the client). I'm not sure where the change in cipher suites comes from (EDH-RSA-DES-CBC3-SHA/DHE-RSA-AES256-SHA), but it shouldn't affect how the certificates are trusted. Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2595939
RE: restlet slower after 2.0 M6
Hello, Laurent, Thanks for quickly re-testing. I've entered a bug report: Internal HTTP client slower than in 2.0 M6 http://restlet.tigris.org/issues/show_bug.cgi?id=1085 As a workaround you can always add the org.restlet.ext.httpclient.jar and its dependencies (Apache HTTP Client). great, and thanks for the workaround, we will give it a try. Regards, Laurent. Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com -Message d'origine- De : webp...@tigris.org [mailto:webp...@tigris.org] Envoyé : vendredi 23 avril 2010 17:41 À : discuss@restlet.tigris.org Objet : RE: restlet slower after 2.0 M6 We had issues in RC2 with our internal HTTP connectors, for example preventing concurrent client requests. Those are fixed in RC3. Could you try again and let us know if you observe a difference? I've just tested with the RC 3, and it seems that it does not change anything. Several runs are still running at = 10 s If you need additional information, I will gladly answers any request. Regards, Laurent. Hi Laurent, We had issues in RC2 with our internal HTTP connectors, for example preventing concurrent client requests. Those are fixed in RC3. Could you try again and let us know if you observe a difference? Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com -Message d'origine- De : Laurent Rustuel [mailto:laurent.rust...@genesyslab.com] Envoyé : vendredi 23 avril 2010 17:07 À : discuss@restlet.tigris.org Objet : restlet slower after 2.0 M6 Hello, I have the feeling that restlet is slower since 2.0 M7. I have tested created a small eclipse project, where a client simply call POST then GET at a resource, 20 times. (see attached file) result are (with System.currentTimeMillis()) total time 10422 ms (10 s) (with restlet 2.0 RC 2) total time 657 ms (0 s) (with restlet 2.0 M6) Does any body have experience the same feeling ? I don't know where exactly something is slower, or if it is in the way I use it. Regards, Laurent. -- Laurent Rustuel, Alten contractor for Genesys, an Alcatel-Lucent Company --- CONFIDENTIALITY NOTICE: This e-mail and any files attached may contain confidential and proprietary information of Alcatel-Lucent and/or its affiliated entities. Access by the intended recipient only is authorized. Any liability arising from any party acting, or refraining from acting, on any information contained in this e-mail is hereby excluded. If you are not the intended recipient, please notify the sender immediately, destroy the original transmission and its attachments and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Copyright in this e-mail and any attachments belongs to Alcatel-Lucent and/or its affiliated entities. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=25935 93 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2593618 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2595947
RE: Re: SSL modifications since 2.0 RC 1 ?
Could you clarify what you mean by accept/ignore? I'm not sure what this means in the context of Firefox/Safari. Right, sorry, that wasn't very clear. Accept: the browser will load the page without complaint. Refuse: the browser will fail to load the page with an error message such as Safari can’t establish a secure connection to the server 'localhost'. Ignore: instructing the browser to ignore the fact that the certificate is self-signed - adding an exception in Firefox, for example. All the tests I've described before are on OS X. are you using client-certificates? Could you explain what configuration you use for the client? (In particular w.r.t the trust store?) I'm not using client-certificates, no. To be honest, I've no idea what a trust store is. The only thing I can think of that might be related to that is the code we use in our tests to disable SSL certificate validation: - set the default host name verifier to an instance that will accept anything. - set the trust manager to a pass-through implementation. I'd be happy to post the code if you need me to. for example, you would have to put your server's self-signed cert into the client's truststore for it to be trusted by the client). This confuses me a bit - I thought that's exactly what I did when I told Safari to add the certificate to the list of trusted certificates. Once I've done that, however, Safari still refuses to load pages. I'm not sure where the change in cipher suites comes from, but it shouldn't affect how the certificates are trusted. What confuses me is that even using the enabledCipherSuites and disabledCipherSuites, I can't change these. Are these instructions ignored in the new version ? Nicolas -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2595972
Re: SSL modifications since 2.0 RC 1 ?
Nicolas Rinaudo wrote: Could you clarify what you mean by accept/ignore? I'm not sure what this means in the context of Firefox/Safari. Right, sorry, that wasn't very clear. Accept: the browser will load the page without complaint. Refuse: the browser will fail to load the page with an error message such as Safari can’t establish a secure connection to the server 'localhost'. Ignore: instructing the browser to ignore the fact that the certificate is self-signed - adding an exception in Firefox, for example. All the tests I've described before are on OS X. OK, from what you're saying, Firefox and Curl work as expected, Safari doesn't and your Restlet 2.0-RC3 based client doesn't either. (I'll leave Safari aside for the moment, as I don't have an OSX machine with me right now.) The main changes that were made regarding SSL between RC1 and RC3 are: 1. Clients no longer use $HOME/.keystore as their keystore by default (it has to be specified if the client wants to use a client-certificate). 2. By default, the SSLContext (on the server connectors) is created by the DefaultSslContextFactory, which follows the defaults of the JSSE Ref guide by default. It will use javax.net.ssl.keyStore, javax.net.ssl.trustStore and related properties if specified, otherwise, the keystore is unspecified (you'd always have to configure it anyway) and the truststore is based on the CA certificates bundled with the JRE. This second change shouldn't break the existing connectors, since it's how they were initialised anyway (except that now, the code is in one place instead of copied across into each connector). It does change the way the Simple connector works, because the simple connector was using the keystore settings for the truststore too. In addition, the Simple connector is set up to ask for an optional client certificate (that's hard-coded in Simple). If the client sends one it doesn't like, this would cause the connection to break. are you using client-certificates? Could you explain what configuration you use for the client? (In particular w.r.t the trust store?) I'm not using client-certificates, no. To be honest, I've no idea what a trust store is. The only thing I can think of that might be related to that is the code we use in our tests to disable SSL certificate validation: - set the default host name verifier to an instance that will accept anything. - set the trust manager to a pass-through implementation. The trust store is the store used by most trust managers (in particular the default one) to load its trusted certificates from. If your client sets its own trust manager as a pass-through implementation, it's likely not to be used. I'd be happy to post the code if you need me to. That could help indeed. It might have to do with how this trust manager is written and passed to the connectors. for example, you would have to put your server's self-signed cert into the client's truststore for it to be trusted by the client). This confuses me a bit - I thought that's exactly what I did when I told Safari to add the certificate to the list of trusted certificates. Once I've done that, however, Safari still refuses to load pages. I'm not sure where the change in cipher suites comes from, but it shouldn't affect how the certificates are trusted. What confuses me is that even using the enabledCipherSuites and disabledCipherSuites, I can't change these. Are these instructions ignored in the new version ? They're not, but not all connectors support them in the same way unfortunately (in some you can enable, in some you can disable). There's little we can do about it, since it depends on the underlying library support (I got a patch in for Jetty a few weeks ago, but I'm not sure it's made it into the release yet). Best wishes, Bruno. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2595999
Cookie authentication
Hi, i have a problem setting the challengescheme in the guard. I've created a guard that decides authentication based on the cookie sent. But when i use the following line: MyGuard mGuard = new MyGuard (getContext(),ChallengeScheme.CUSTOM, Tradefields API Login); In runtime i get: Challenge scheme CUSTOM not supported by the Restlet engine. In the javadocs it says about ChallengeScheme.CUSTOM Custom scheme based on IP address or cookies or query params, etc. I've read about extending AuthenticationHelper but it demands a ChallengeScheme constant and i don't need a challenge (just to ignore when the credentials found in the cookie are wrong). How should i follow? Thanks! -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Cookie-authentication-tp4963859p4963859.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2596099
Re: Restlet and DAO
Hi Nico, UniformResource has two methods, doInit() and doRelease() that can be used for this. However, be careful with your transaction strategy if your representations need access to the DAO at writing time (after afterHandle() is called, in the connector).You can used ServerResource#onSent callback for this or the ConnectorService#afterSend method. Best regards, Jerome Louvel -- Restlet ~ Founder and Technical Lead ~ http://www.restlet.org Noelios Technologies ~ http://www.noelios.com 2010/4/26 Nico Van Cleemput nico.vancleem...@gmail.com Yes, I had thought about that, but a filter has a beforeHandle() and a afterHandle() method, so I can easily set up a transaction before the handling and easily perform a commit or a rollback in after the handling. If I would use a BaseResource I would need to add these calls for each extending class, or are there provisions for such a use? Although thinking it through again at this moment, I probably need to overwrite the handle() method in ServerResource to obtain this behaviour? Thanks, Nico -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/Restlet-and-DAO-tp4962381p4962438.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2595911 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2596144
can i use ijetty as a server and host restlet service on android?
hi: i have a problem while using ijetty as a server on android to host restlet service, the helloworld example. i try to access it from my laptop and the android emulator web browser but both of them do not work. the ijetty says that the service is unavailable. but if i deploy the service in tomcat in my pc, then i can access it from my android emulator. so i wonder wether i can use ijetty as a server on android to host restlet service or not. and if i can, what steps should i follow. thanks a lot. keith -- View this message in context: http://restlet-discuss.1400322.n2.nabble.com/can-i-use-ijetty-as-a-server-and-host-restlet-service-on-android-tp4966008p4966008.html Sent from the Restlet Discuss mailing list archive at Nabble.com. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=2596411
