subject:"RE\: securing Restlet"

RE: securing Restlet 1.2

2009-01-13 Thread Jerome Louvel

Hi all,

Let's continue this discussion in the developers mailing list. 

See my reply there:
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=7458dsMessageId=1022072

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 3 janvier 2009 00:19
A : discuss@restlet.tigris.org
Objet : securing Restlet 1.2

hello all,

i went through the 13 High priority enhancements for Restlet 1.2 in the 
Requirements section of Security re-factoring found here 
(http://wiki.restlet.org/developers/172-restlet/212-restlet.html) and tried 
to classify them in order to come up with an implementation plan.  here are 
my thoughts:

* the only one comprehensive approach for covering Authentication and 
Authorization needs is JSecurity ([I658] Add support for JSecurity).  if 
implemented, this would IMO also achieve:

  # [I288] Support pre-emptive authentication
  # [I503] Give access to connector authentication
  # [I504] Add notion of realm
  # [I605] Support cookie based authentication

the other requirements, excluding [I505] Re-factor authentication and 
authorization, can be classified as:

* add support for more/other authentication mechanisms.  these could be 
achieved by implementing JSecurity classes (in org.jsecurity.authc packages) 
either in the JSecurity project, or here and contributing them to that 
project:

  # [I444] Support SPNEGO authentication
  # [I446] Support OpenID authentication
  # [I447] Support JAAS authentication

* improving the current mechanisms.  these could be achieved by designing 
the framework to allow (at least the Guard) to inject security constraints 
and have the (Guard) methods delegate the work to the security framework.  
this way the existing (and future) work done on the Guard would not be lost 
or in need of (too much) re-writing:

  # [I485] Support htpasswd encrypted files in Guard
  # [I567] Improve HTTP Digest support
  # [I606] Improve OAuth extension
  # [I634] Guard.checkSecret should accept a Response object


i'm seeking feedback on the following proposed plan:

* adopt JSecurity (http://www.jsecurity.org/) as the base Authentication and 
Authorization provider for Restlet.  their code is published under an Apache 
2.0 Open Source License, and the project itself is in incubation state for 
becoming an Apache product.

* hide as little as possible JSecurity classes in Restlet.  this basically 
means adding a dependency to the Restlet Core on the JSecurity JARs --for 
JDK 5 and later, the following is a minimum (when the security services are 
enabled): jsecurity.jar, commons-logging.jar; for heterogeneous clients, SSO 
support: ehcache.jar, and backport-util-concurrent.jar.

* add one service (SecurityService in org.restlet.service) and enough 
classes in Restlet (mainly org.restlet.security package) to configure, 
enable/disable and use the JSecurity classes.

* re-factor Guard to re-use the above so its existing sub-classes can 
continue to work unchanged.


at a later stage, i think it could be beneficial to look at how we can 
configure and use this security framework separately or in collaboration at 
the Component, VirtualHost and Application levels.


cheers;
rsn

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

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

RE: securing Restlet

2008-12-28 Thread Jerome Louvel

Hi Raif,

Cool! 

Regarding the SecurityManager, this won't be part of Restlet 1.2 but I think it 
is an important aspect of the overall Restlet
security domain (authorization enforcement) so I like to keep in the context.

However, I have separated RFEs on the page between high priority ones (Restlet 
1.2 ideally) or others.

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 : vendredi 26 decembre 2008 11:42
A : discuss@restlet.tigris.org
Cc : Jerome Louvel
Objet : 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

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

RE: securing Restlet

2008-12-28 Thread Jerome Louvel

Hi Rémi,

That sounds like a great contribution. Maybe we should try to integrate your
solution with Rob's CookieUtility for the cookie generation. Isn't his solution
more robust that your simple timestamp?

Let me know if there is any issue with the JCA. Otherwise, could you attach the
source code directly to the RFE so we can have a closer look at your design to
further discuss it?

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

De : remidewi...@gmail.com [mailto:remidewi...@gmail.com] De la part de Rémi
Dewitte
Envoyé : vendredi 26 décembre 2008 14:39
À : discuss@restlet.tigris.org
Objet : 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 485
http://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.com wrote:

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=4447
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=989993
dsMessageId=989993

http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447dsMessageId=992857
dsMessageId=992857

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

RE: securing Restlet

2008-12-26 Thread Jerome Louvel

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

2008-12-26 Thread Jerome Louvel

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: securing Restlet

2008-12-26 Thread Jerome Louvel

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

2008-12-26 Thread Jerome Louvel

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

26 matches

Mail list logo