quot;/loginForm");
}
The Pieter Martin suggested every thing, but changing the
loginPath("/rest/special/loginPost") made me confusion. I thought I should
do something in the post method.
Thanks,
Ramesh
--
View this message in context:
http://res
String password = form.getFirstValue("password");
String targetURI = getQueryValue("targetURI");
..//What todo here ???
}
- Ramesh
--
View this message in context:
http://restlet-discuss.1400322.n2.nabble.com/How-to-use-CookieAuthenticat
Hi all,
Based on this ongoing discussion, it would be clearly useful to include a
CookieAuthenticator example in Restlet user guide.
Added new issue. If anyone wants to contribute a Markdown page for this
that would be great:
https://github.com/restlet/restlet-framework-java/issues/837
Also, I'v
Pieter Martin lavabit.com> writes:
>
> Hi,
>
> Took me a while but I did get it working,
>
> Here is what I did.
>
> In my restlet application I set up the CookieAuthenticator as follows
>
> public class CMRestletApplication extends Application {...
>
Hi Pieter Martin,
Thanks for the exa
Ah yes, something like the client's IP address would make sense. I will have to
think on what information we would like to include, but at least now I know
that what I want is indeed possible :)
And you are right, those 3 levels of protection should be sufficient, but I am
still missing one of
On Fri, Jul 12, 2013 at 9:32 AM, Johanneke Lamberink
wrote:
> But what would I put in there? Let's call it a sessionID, regardless of
> the actual content. The only way this will give the protection I need
> requires some sort of state on the server, doesn't it?
>
You could store some information
But what would I put in there? Let's call it a sessionID, regardless of the
actual content. The only way this will give the protection I need requires some
sort of state on the server, doesn't it?
So I guess my question is, is it possible to protect against this specific
attack while maintainin
You can override the formatCredentials and parseCredentials methods to
store custom information in the (encrypted) cookie value.
On Fri, Jul 12, 2013 at 9:12 AM, Johanneke Lamberink
wrote:
> Thanks for the reply. Yes, treating old cookies as stale is what I do now.
> I was wondering if there is a
Thanks for the reply. Yes, treating old cookies as stale is what I do now. I
was wondering if there is another way to prevent re-use of an old cookie.
--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3060332
You can always have the Verifier treat cookies with creation times too far
in the past as stale. A legitimate client will be able to provide the
credentials again; an impostor with a stolen cookie won't.
--tim
On Fri, Jul 12, 2013 at 6:01 AM, Johanneke Lamberink
wrote:
> When a user requests a l
When a user requests a logout, the 'maxAge' of the cookie is set to 0, which
will tell the browser to delete it.
However, when a cookie was stolen, this stolen cookie still exists, and can
still be used to log in. After all, the cookie contains all the information
needed for logging in, no add
Hi,
I have not looked at the code for a while but my understanding was that
the cookie is invalidated when the user logs out. So it can not be
reused after a logout.
Cookies are (optionally) set to expire after some time of no use.
Cheers
Pieter
On 12/07/2013 11:21, Johanneke Lamberink wrote:
Well, yes, I believe that when using HTTPS, stealing a cookie means access to
the computer. But people let other people use their computer, or your laptop
might get stolen, or you might forget to lock it when you go out for lunch.
Because of the premise that you need physical access to the compu
The above is assuming that https is being used.
Thanks
Pieter
On 12/07/2013 10:32, Pieter Martin wrote:
> I would also like to know about this.
>
> However is stealing a cookie not the same as getting access to the users
> computer?
>
> Cheers
> Pieter
>
> On 12/07/2013 09:53, Johanneke Lamberink
I would also like to know about this.
However is stealing a cookie not the same as getting access to the users
computer?
Cheers
Pieter
On 12/07/2013 09:53, Johanneke Lamberink wrote:
> So, as far as I can see, the Restlet CookieAuthenticator takes care of
> session fixation by generating a new
So, as far as I can see, the Restlet CookieAuthenticator takes care of session
fixation by generating a new value for the cookie on every request (encrypting
the username/password/timestamp).
But what about session hijacking? If every cookie contains the username and
password, someone who got h
Ok, part of my confusion was because of my inexperience with cookies.
The current login flow of my application is like this:
Do a POST to the loginPath().
If the credentials are valid a cookie is set, and the resource of the
loginPath() returns some additional information.
If the credentials a
Hi,
Took me a while but I did get it working,
Here is what I did.
In my restlet application I set up the CookieAuthenticator as follows
public class CMRestletApplication extends Application {...
@Override
public Restlet createInboundRoot() {
Router router = new Router(getCon
So I'm trying to use the CookieAuthenticator, but there are some things unclear
to me. The documentation focuses on explaining how to do HTTP Basic or HTTP
Digest, I haven't been able to find an example of HTTP Cookie anywhere, which
is a shame :(
I am using Restlet 2.1.2.
Question 1
19 matches
Mail list logo
