RE: contributing - areas of interest
Hi Raif, The main reason for using manual DOM-based parsing of XML files is mainly to prevent any dependency beside JDK/JRE API. Also, the restlet.xsd schema is trying to match exactly the structure and property of Restlet API classes. In some way, the API classes are the DAO beans... definitely a special case in my mind. Another major concern is keeping the core Restlet as compact as possible. It would be possible to add those DAO beans in the Restlet engine package though without cluttering the Restlet API itself. In a normal project, I would definitely not write the XML code by hand and prefer a generated approach like JAXB or EMF. Anyway, you make a good point regarding the support of other serialization formats (JSON would be nice). I suggest that you open a RFE to cover those requirements and remarks so we keep thinking about them in the future. Regarding the next steps for security, I'll reply to the other thread securing Restlet :) 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 : Raif S. Naffah [mailto:tig...@naffah-raif.name] Envoye : jeudi 25 decembre 2008 08:03 A : discuss@restlet.tigris.org Cc : Jerome Louvel Objet : Re: contributing - areas of interest hello Jerome, On Wednesday 24 December 2008 06:56:47 Jerome Louvel wrote: Hi Raif, Cool! * Java Bindings to XML Schemas: we already support JAXB and JiBX technologies. What would adding an extension for XMLBeans add (pros/cons)? There are many serializations technologies to consider (Castor comes to mind) so we need to be very selective in what we add to the main Restlet project. i thought of this while working on the patch for supporting init-param (Issue #670) in the org.restlet package and not as another Extension. the current code relies only on the DOM structure of a restlet.xml file. my suggestion is to replace those bits by (a) pre-compiling schema-to-Java bindings for whatever is defined in the Components.xsd --which today is not much but could be a subject of change depending on how authentication and authorization will be configured in the future-- and (b) replacing the Component and other classes configuration and initialization based on the Data Access Objects representing a successful parsing of a restlet.xml. the current code has the advantage of not relying on other than a JDK but also has the disadvantage IMO of not separating the configuration from the other life-cycle states of software components. in addition having those Java Binding classes would allow configuring a Restlet application through other than a restlet.xml file. * authorization toolkit: thanks for the pointer to Tomcat Realms, I've added a comment about it in issue #505. This is definitely an area that would benefit from contributions during Restlet 1.2 development cycle! great. * KML/KMZ support: this might be a too application specific to fit into the main Restlet project, but you could start a dedicated open source project (for example on Google Code), that would leverage Restlet. We would be happy to point users to it and support you. makes sense. what's the next step? 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 : Raif S. Naffah [mailto:tig...@naffah-raif.name] Envoye : lundi 8 decembre 2008 09:05 A : discuss@restlet.tigris.org Objet : contributing - areas of interest hello there, (i'm sending this again since it does not look like it made it to the list the first time around). i'd like to contribute to this project in my free time. areas of interests which i've identified so far --and am personally interested in-- are: * Java Bindings to XML Schemas: replace XML parsing with pre-generated classes (XMLBeans xmlbeans.apache.org) from published/known schemas; e.g. the parsing of the restlet.xml. * authorization toolkit: something equivalent to what is available with servlets in Apache Tomcat; see http://tomcat.apache.org/tomcat-6.0- doc/realm-howto.html. * KML/KMZ support: something beyond issue #677; more like a SPI toolkit to allow building KML files (e.g. from a CSV document). if this is of interest to the project maintainers, then pls. let me know how to proceed next. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=98 1057 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=99 0910 -- cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=992116 --
RE: Metadata service
Great :) Happy Holidays! Jerome -Message d'origine- De : fabio.mancine...@gmail.com [mailto:fabio.mancine...@gmail.com] Envoye : jeudi 25 decembre 2008 19:03 A : discuss@restlet.tigris.org Objet : RE: Metadata service Yes I was able to solve the issue. It was the getTunnelService().setExtensionsTunnel(true); that had to be called to enable conneg via extensions. Thank you for your help and merry xmas! :) Fabio -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=992502 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=992810
Re: Sample code for using FreeMarker with Restlets
hello Mark, On Friday 26 December 2008 07:17:55 Mark Petrovic wrote: Good day, and Merry Christmas to all who are celebrating it. Would someone be kind enough to post a few lines of example config and code showing how you use FreeMarker with Restlets in returning html views. the org.restlet.example folder (in the src folder of the restlet-1.1.1.zip) contains a comprehensive example of how to use FreeMarker with Restlet specifically the code in org/restlet/example/book/restlet/ch8. Thanks much. -- Mark Petrovic m...@petrovic.org http://www.petrovic.org -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=99 2541 cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=992830 signature.asc Description: This is a digitally signed message part.
RE: securing Restlet
Hi Raif, This is a good start. We have a page on the developers' wiki that should be used during this refactoring project. I have updated it based on the issues and discussions you have selected, extending to all other I could find. Security refactoring http://wiki.restlet.org/developers/172-restlet/212-restlet.html You should create an account on the wiki, and then update the page (section Analysis/Synthesis, with the main points you have reported below. See instructions to register here: Restlet Wiki Site http://wiki.restlet.org/about/2-restlet.html 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 : Raif S. Naffah [mailto:tig...@naffah-raif.name] Envoye : jeudi 18 decembre 2008 10:34 A : discuss@restlet.tigris.org Objet : securing Restlet hello all, as a follow up to my original post re. contributing to the project (see http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=981057), and after digesting the suggestions and responses that followed, here's a summary of the discussion threads and issues (see list at the end) related to the above subject i was able to find to-date. pls. let me know if i missed, mis-interpreted, or overlooked anything pertaining to the issue: * there's a recognized need for better, more pluggable authentication and authorization (AA) capabilities within the Restlet project. * successful integration with both Spring Security (Acegi Security http://acegisecurity.org/) and JSecurity (http://jsecurity.org/) were reported. * the Guard class does not seem to always suit developers' needs when it comes to integrating external security libraries to offer AA capabilities. Filter was used successfully and Resolver was suggested for authorization needs beyond URIs. * there was no direct mention about securing the Restlet library code itself separately from users application; e.g. if using the Java SE Security what would be a conservative security policy and permissions to use/grant. * it's unclear (to me at least) whether the desired outcome is to integrate one (of many) external security library, or build within Restlet a commons layer and artifacts (configuration data) to allow (and map to) different ones. the other two subjects mentioned in the other post remain of interest to me as well. i look forward to the input of the project maintainers. references: [D1] Spring Security Integration http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=40454 [D2] Restlet Servlet and Security http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=58357 [D3] Re: What is missing from Restlet? http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=94828 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=95151 [D4] Security Issues with Dynamic Loading of Applications? http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=963302 [I264] Support Spring Security http://restlet.tigris.org/issues/show_bug.cgi?id=264 [I505] Refactor authentication and authorization http://restlet.tigris.org/issues/show_bug.cgi?id=505 [I658] Add support for JSecurity http://restlet.tigris.org/issues/show_bug.cgi?id=658 -- cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=986463 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=992831
RE: securing Restlet
I've added Raif's comment about Tomcat realms to this issue: Add notion of realm http://restlet.tigris.org/issues/show_bug.cgi?id=504 Regarding the plumbing, we have a design approach for Restlet that says that everything should be configurable programmatically first (via the Restlet API). Then, on a case-by-case basis, we can offer alternative ways of configuring the Restlet API beans (ex: Component and connectors for now, Application and guards in the future). I agree that things that are likely to be changed by an administrator should be modifiable without recompilation, but there are many ways to support this scenario. Using local static XML/JSON/properties files is just one way. Some alternatives are REST APIs, HTML console, GWT console, JMX, database. Finally, I very much agree on the ideas of authentication grades and impact on authorization. I've added them in the Analysis/Synthesis section: http://wiki.restlet.org/developers/172-restlet/212-restlet.html 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 : Raif S. Naffah [mailto:tig...@naffah-raif.name] Envoye : samedi 20 decembre 2008 01:01 A : discuss@restlet.tigris.org Cc : Stephan Koops Objet : Re: securing Restlet hello Stephan, my comments are in-lined. On Friday 19 December 2008 19:49:12 Stephan Koops wrote: Hi Raif, I think it is good, if a developer could build a HTML application with Restlet, where he could give a typical login HTML web page and the user could login without the browsers HTTP authentication prompt (because you can't design it and so on). In Servlet apps you typically use sessions, but this we don't want. But we can use Cookies for it, which shows, who is logged in. It would be very good, if we (optionally) use a cryptical check, so that nobody could create it's own Cookie by hand to fake a logged in user. This should be a ready-to-use-class a developer could instantiate, plug an authentication mechansim in it (Basic, Digest, ...), an authenticator (against a file (as in apache e.g.), a database, a JSecurity, ...) and go. yes. this is where i started from: essentially a clone of what is available with servlets in Apache Tomcat. if we have this in Restlet then a developer would be able to configure Authentication based on credentials accessed from different Realms. this with developer's own HTML (JSP really) form provided the user-name and the password fields are specifically named. the page here (http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html) has more details. plumbing-wise i thought of using the restlet.xml as the primary way for configuring the Realm. directly using the classes should also work albeit is not recommended. for one, you don't want to modify and recompile your code if you decide later you want to use another Realm, and two, sometimes choosing which Realm to use is the privilege of the Administrator running the application not its developer. Another possibility to not require the browser login prompt is to use an AJAX reqeust and set the credentials in it. I've implemented this, but I needed a new return status for it, because if the server returns 401 (authentication required / invald) to the client, then the browser would open a login prompt. If needed, a could attach it to issue 505 It is also good, if it is allowed to have multiple authentication mechanims allowed for one resource, e.g. with cookies as descibed above for browsers and with a HTML authentiction for software clients, which requesting e.g. XML or JSON. correct me if i'm wrong but if the aim of the Authentication is to assert who are you then your identity should be the same whatever Authentication mechanism was used. in that respect _one_ Authentication mechanism should be enough. on the other hand, what are you allowed to do (incl. what type of Representation for a requested Resource) is the domain of Authorization. in that respect one (of potentially several conditions, incl. for example the time-of-day) for authorizing a type of Representation could be the grade of the Authentication mechanism used to establish your identity; i.e. an Authentication mechanism based on a personal X.509 Certificate has a higher grade than one based on non-encrypted user-name and password. what could be gained though from having an aggregation/compounded style of user-credentials gathering mechanisms would be to increase the trust in the established identity. e.g. i would have more confidence in your identity if i can check your credentials from two separate sources; as a consequence i can then authorize you to do more. best regards Stephan Raif S. Naffah schrieb: hello all, as a follow up to my original post re. contributing to the project (see http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId= 981057),
Re: contributing - areas of interest
hello Jerome, On Friday 26 December 2008 19:20:03 Jerome Louvel wrote: Hi Raif, The main reason for using manual DOM-based parsing of XML files is mainly to prevent any dependency beside JDK/JRE API. Also, the restlet.xsd schema is trying to match exactly the structure and property of Restlet API classes. In some way, the API classes are the DAO beans... definitely a special case in my mind. Another major concern is keeping the core Restlet as compact as possible. It would be possible to add those DAO beans in the Restlet engine package though without cluttering the Restlet API itself. In a normal project, I would definitely not write the XML code by hand and prefer a generated approach like JAXB or EMF. Anyway, you make a good point regarding the support of other serialization formats (JSON would be nice). I suggest that you open a RFE to cover those requirements and remarks so we keep thinking about them in the future. done: http://restlet.tigris.org/issues/show_bug.cgi?id=696 Regarding the next steps for security, I'll reply to the other thread securing Restlet :) great! 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 : Raif S. Naffah [mailto:tig...@naffah-raif.name] Envoye : jeudi 25 decembre 2008 08:03 A : discuss@restlet.tigris.org Cc : Jerome Louvel Objet : Re: contributing - areas of interest hello Jerome, On Wednesday 24 December 2008 06:56:47 Jerome Louvel wrote: Hi Raif, Cool! * Java Bindings to XML Schemas: we already support JAXB and JiBX technologies. What would adding an extension for XMLBeans add (pros/cons)? There are many serializations technologies to consider (Castor comes to mind) so we need to be very selective in what we add to the main Restlet project. i thought of this while working on the patch for supporting init-param (Issue #670) in the org.restlet package and not as another Extension. the current code relies only on the DOM structure of a restlet.xml file. my suggestion is to replace those bits by (a) pre-compiling schema-to-Java bindings for whatever is defined in the Components.xsd --which today is not much but could be a subject of change depending on how authentication and authorization will be configured in the future-- and (b) replacing the Component and other classes configuration and initialization based on the Data Access Objects representing a successful parsing of a restlet.xml. the current code has the advantage of not relying on other than a JDK but also has the disadvantage IMO of not separating the configuration from the other life-cycle states of software components. in addition having those Java Binding classes would allow configuring a Restlet application through other than a restlet.xml file. * authorization toolkit: thanks for the pointer to Tomcat Realms, I've added a comment about it in issue #505. This is definitely an area that would benefit from contributions during Restlet 1.2 development cycle! great. * KML/KMZ support: this might be a too application specific to fit into the main Restlet project, but you could start a dedicated open source project (for example on Google Code), that would leverage Restlet. We would be happy to point users to it and support you. makes sense. what's the next step? 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 : Raif S. Naffah [mailto:tig...@naffah-raif.name] Envoye : lundi 8 decembre 2008 09:05 A : discuss@restlet.tigris.org Objet : contributing - areas of interest hello there, (i'm sending this again since it does not look like it made it to the list the first time around). i'd like to contribute to this project in my free time. areas of interests which i've identified so far --and am personally interested in-- are: * Java Bindings to XML Schemas: replace XML parsing with pre-generated classes (XMLBeans xmlbeans.apache.org) from published/known schemas; e.g. the parsing of the restlet.xml. * authorization toolkit: something equivalent to what is available with servlets in Apache Tomcat; see http://tomcat.apache.org/tomcat-6.0- doc/realm-howto.html. * KML/KMZ support: something beyond issue #677; more like a SPI toolkit to allow building KML files (e.g. from a CSV document). if this is of interest to the project maintainers, then pls. let me know how to proceed next. -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId= 98 1057 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId= 99 0910 -- cheers; rsn
RE: securing Restlet
Good exchange! I've added some excerpts as comment to this issue: Support cookie based authentication http://restlet.tigris.org/issues/show_bug.cgi?id=605 Cheers, Jerome -Message d'origine- De : Rhett Sutphin [mailto:rh...@detailedbalance.net] Envoye : lundi 22 decembre 2008 00:38 A : discuss@restlet.tigris.org Objet : Re: securing Restlet On Dec 20, 2008, at 6:49 PM, Raif S. Naffah wrote: On Sunday 21 December 2008 09:05:46 Rhett Sutphin wrote: On Dec 20, 2008, at 3:34 PM, Raif S. Naffah wrote: hello Stephan, On Sunday 21 December 2008 00:41:48 Stephan Koops wrote: Hi Raif, Another possibility to not require the browser login prompt is to use an AJAX reqeust and set the credentials in it. I've implemented this, but I needed a new return status for it, because if the server returns 401 (authentication required / invald) to the client, then the browser would open a login prompt. If needed, a could attach it to issue 505 It is also good, if it is allowed to have multiple authentication mechanims allowed for one resource, e.g. with cookies as descibed above for browsers and with a HTML authentiction for software clients, which requesting e.g. XML or JSON. correct me if i'm wrong but if the aim of the Authentication is to assert who are you then your identity should be the same whatever Authentication mechanism was used. in that respect _one_ Authentication mechanism should be enough. on the other hand, what are you allowed to do (incl. what type of Representation for a requested Resource) is the domain of Authorization. in that respect one (of potentially several conditions, incl. for example the time-of-day) for authorizing a type of Representation could be the grade of the Authentication mechanism used to establish your identity; i.e. an Authentication mechanism based on a personal X. 509 Certificate has a higher grade than one based on non-encrypted user-name and password. what could be gained though from having an aggregation/ compounded style of user-credentials gathering mechanisms would be to increase the trust in the established identity. e.g. i would have more confidence in your identity if i can check your credentials from two separate sources; as a consequence i can then authorize you to do more. Here I was not precise enough: I meant alternative authentication mechanisms, not both must be passed. If I use a software client (web service), than basic or digest is fine, but if the client is a browser, than the cookie based may be better, because it allows corporate design: I think, a reason for not using REST styled web apps in the commercial is, that authentication in corporate design is more difficult than with Servlets: If the developer says to the manager: We have two alternatives: One allows corporated design to be used easily, and the other options has problems with it, what would he say? Right, he will say: Use the options which allows it. i see what you mean but just to clarify: Cookies per se are not an authentication mechanismbut a technique to maintain a state which could be used to claim previous alleged successful authentication. Right, I fully agree with you; that was my idea. even then, i see two problems with Cookies: (a) users can have their Browsers reject them, Yes, I know. That is really a problem. and (b) they contradict the REST principle (see section 6.3.4.2 of R. Fielding dissertation http://roy.gbiv.com/pubs/dissertation/evaluation.htm). You are right, that cookies produces problems, if they contain application state, e.g. to match a Servlet session. But IMO it is not a problem, if you only save, that the user is logged in and it's user name (perhaps secured by an additional crypto hash or something like that). i agree with you that allowing Restlet users/developers to plug-in their own customized log-in form where user credentials can be obtained will be a selling point. this i think can be achieved by implementing in Restlet something similar to what the Servlet specs' login- config and auth- method elements provide. And how do a Servlet Container check the authentication? It could only set a cookie or use a session and save it in the session. No we have back the cookies, or - worse - a session. but doesn't the current Guard implementation obviate the need for both sessions and cookies, and yet provide us with basic authentication? if yes, then a solution for providing customizable form-based login could be to extend its capabilities to allow declaring and re-directing to a resource URI to use when the credentials are missing. does this make sense? No, that won't work. The reason why basic auth works without prompting after the first request is that the browser caches the credentials and repeats the Authorization header with every subsequent request. This is possible because basic authentication
RE: securing Restlet
Hi Stephan, I've added a link from the RFE to Remi's implementation: Support cookie based authentication http://restlet.tigris.org/issues/show_bug.cgi?id=605 However, we would need Remi to offer his implementation to Restlet code base in order to consider this integration. Remi, see this page if you are interested in contributing your code: http://www.restlet.org/community/contribute Also, Rob Heittman previously a CookieUtility class to the public domain: http://gogoego.googlecode.com/svn/trunk/modules/RestletFoundation/src/com/solertium/container/CookieUtility.java 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 : Stephan Koops [mailto:stephan.ko...@web.de] Envoyé : lundi 22 décembre 2008 19:32 À : discuss@restlet.tigris.org Objet : Re: securing Restlet Hi Rémi, cool. Jerome, Thierry: Could we add it to the code base, if the security is refactored? best regards Stephan I have made a cookie authentication for restlet. Here is the code. Few things might not be clean but it works quite fine. I hope it helps. Rémi ___ Täglich 1.000.000 Euro gewinnen! Jetzt kostenlos WEB.DE MillionenKlick spielen! https://millionenklick.web.de/?mc=m...@footer.mklick@home -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=989993 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=992857
Re: securing Restlet
hello Jerome, On Friday 26 December 2008 20:14:02 Jerome Louvel wrote: Hi Raif, This is a good start. We have a page on the developers' wiki that should be used during this refactoring project. I have updated it based on the issues and discussions you have selected, extending to all other I could find. Security refactoring http://wiki.restlet.org/developers/172-restlet/212-restlet.html You should create an account on the wiki, and then update the page (section Analysis/Synthesis, with the main points you have reported below. See instructions to register here: Restlet Wiki Site http://wiki.restlet.org/about/2-restlet.html account created and Docs Author karma granted. thanks! the page as it stands is very comprehensive and IMO does not need at this stage any amendments since it already addresses all the points raised. if i could make one suggestion it would be to separate the work on the SecurityManager (and associated policy file) from the Authentication and Authorization aspects since these two tasks can be done in parallel. 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 : Raif S. Naffah [mailto:tig...@naffah-raif.name] Envoye : jeudi 18 decembre 2008 10:34 A : discuss@restlet.tigris.org Objet : securing Restlet hello all, as a follow up to my original post re. contributing to the project (see http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=98 1057), and after digesting the suggestions and responses that followed, here's a summary of the discussion threads and issues (see list at the end) related to the above subject i was able to find to-date. pls. let me know if i missed, mis-interpreted, or overlooked anything pertaining to the issue: * there's a recognized need for better, more pluggable authentication and authorization (AA) capabilities within the Restlet project. * successful integration with both Spring Security (Acegi Security http://acegisecurity.org/) and JSecurity (http://jsecurity.org/) were reported. * the Guard class does not seem to always suit developers' needs when it comes to integrating external security libraries to offer AA capabilities. Filter was used successfully and Resolver was suggested for authorization needs beyond URIs. * there was no direct mention about securing the Restlet library code itself separately from users application; e.g. if using the Java SE Security what would be a conservative security policy and permissions to use/grant. * it's unclear (to me at least) whether the desired outcome is to integrate one (of many) external security library, or build within Restlet a commons layer and artifacts (configuration data) to allow (and map to) different ones. the other two subjects mentioned in the other post remain of interest to me as well. i look forward to the input of the project maintainers. references: [D1] Spring Security Integration http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=40 454 [D2] Restlet Servlet and Security http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=58 357 [D3] Re: What is missing from Restlet? http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=94 828 http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=95 151 [D4] Security Issues with Dynamic Loading of Applications? http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=96 3302 [I264] Support Spring Security http://restlet.tigris.org/issues/show_bug.cgi?id=264 [I505] Refactor authentication and authorization http://restlet.tigris.org/issues/show_bug.cgi?id=505 [I658] Add support for JSecurity http://restlet.tigris.org/issues/show_bug.cgi?id=658 -- cheers; rsn -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=992872 signature.asc Description: This is a digitally signed message part.
Re: securing Restlet
Jerome, I will do all the necessary to allow the code to be integrated as soon as possible. A little description of what I will submit. Few lines to describe a little bit more what's in the CookieGuard : - guard intercepts /login and /logout path requests, the behaviour is of customizable - on /login, it performs authentication thanks to the SecretResolver and set a ChallengeResponse to the request - on /logout, make the cookie expires now - on any other request, try to decrypt the cookie and set a ChallengeResponse to the request What's in the cookie = value of the cookie ? - the username - a timestamp We could embed even more information from the client but i don't really think it is necessary. Is it secure ? - Yes the value is encrypted thanks to a Cipher (from JRE), making difficult to read values embedded in the cookie. - timestamp embedded in the cookie allows to check for expiration serverside without storing anything, making difficult to exploit a stolen cookie for a long time. Client is responsible from maintaining the state. It is stateless. It is fast. In the code you can also find some code to read (and write) passwords from a standard htpasswd file addressing in a different way issue 485http://restlet.tigris.org/issues/show_bug.cgi?id=485 . Also my authoriseMissing suggestion renamed as optionalAuthentication in the code. Rémi On Fri, Dec 26, 2008 at 11:05, Jerome Louvel jerome.lou...@noelios.comwrote: Hi Stephan, I've added a link from the RFE to Remi's implementation: Support cookie based authentication http://restlet.tigris.org/issues/show_bug.cgi?id=605 However, we would need Remi to offer his implementation to Restlet code base in order to consider this integration. Remi, see this page if you are interested in contributing your code: http://www.restlet.org/community/contribute Also, Rob Heittman previously a CookieUtility class to the public domain: http://gogoego.googlecode.com/svn/trunk/modules/RestletFoundation/src/com/solertium/container/CookieUtility.java 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 : Stephan Koops [mailto:stephan.ko...@web.de] Envoyé : lundi 22 décembre 2008 19:32 À : discuss@restlet.tigris.org Objet : Re: securing Restlet Hi Rémi, cool. Jerome, Thierry: Could we add it to the code base, if the security is refactored? best regards Stephan I have made a cookie authentication for restlet. Here is the code. Few things might not be clean but it works quite fine. I hope it helps. Rémi ___ Täglich 1.000.000 Euro gewinnen! Jetzt kostenlos WEB.DE MillionenKlick spielen! https://millionenklick.web.de/?mc=m...@footer.mklick@home -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=989993 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=992857 -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=992930
Re: Solr integration
Very much interested. Thanks Duong BaTien DBGROUPS and BudhNet On Fri, 2008-12-26 at 14:45 +0100, Rémi Dewitte wrote: Hello, While doing some cleanup to contribute to the authentication work, I thought I could give a restlet integration of Solr. Basically it is a ClientHelper handling solr://... request. I just need to know whether someone is interested in it. Cheers, Rémi -- http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=992999
Re: securing Restlet
Guilty as charged, fixed on my copy and never sent the patch back to the
Restlet list. Will do when I get back from holiday travels!
On Fri, Dec 26, 2008 at 12:36 PM, Tim Peierls t...@peierls.net wrote:
On Fri, Dec 26, 2008 at 5:05 AM, Jerome Louvel jerome.lou...@noelios.com
wrote:
Also, Rob Heittman previously a CookieUtility class to the public domain:
http://gogoego.googlecode.com/svn/trunk/modules/RestletFoundation/src/com/solertium/container/CookieUtility.java
There is a race condition in this code, in newUniqueID:
final long lincr = incr.getAndIncrement();
if (lincr Integer.MAX_VALUE)
incr.set(0);
I think Rob meant to fix this, but didn't get around to it. Here's a
reasonable fix for those lines:
long lincr;
while (true) {
lincr = incr.get();
long next = lincr Integer.MAX_VALUE ? (lincr + 1) : 0;
if (incr.compareAndSet(lincr, next))
break;
// Another thread interfered; try again.
}
--tim
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=993203
