esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Pollak <feeder.of.the.be...@gmail.com>
Subject Re: Token Problem in browser-based clients
Date Wed, 04 Feb 2009 17:32:51 GMT
Having the token in the HTML is not insecure.

The HTML with the token will only be generated if the user can log in based
on their current cookies.  If they have current cookies to log in, then they
can access the token anyway by navigating to the token page.

But the token and API login should be unnecessary as the browser send the
current cookies with the current session along with every HTTP request.

On Wed, Feb 4, 2009 at 12:53 AM, Darren Hague <dhague@fortybeans.com> wrote:

> Hi Dick,
>
> How about just having a "Login token" HTML form element + button in the
> screen for the user to fill in? When they click "submit", a JavaScript event
> handler would (a) set the "token" variable & log into ESME, and (b) hide the
> login element + button.
>
> That means that you are not hard-coding the token in the source code, and
> the user's browser will remember the token for next time using the standard
> browser autofill functionality.
>
> Would that work for you?
>
> Failing that, you need to be a bit clearer about where you would want to
> store the token, in a way that it could not be read...
>
> Cheers,
> Darren
>
> >Currently, the ESME login requires a token. This is no problem when
> >using Java, C#, etc. However, in clients that are based in the browser
> >(such as pure-JavaScript clients -
> >http://code.google.com/p/esmeproject/wiki/PureJavascript_messaging_clien
> >t), the token is visible in the HTML source code. Obviously, this isn't
> >very secure.
> >
> >In the quest to use the long-polling features of the browser without
> >revealing the token, we've been exploring various alternatives. We've
> >tried logging-in via java,  rewriting the JSESSIONID cookie to the
> >browser and then using this cookie in subsequent REST API calls. This
> >attempt failed inasmuch as ESME didn't accept the java-based session
> >cookie for the JavaScript-based REST API calls.
> >
> >Anyone have any other ideas to deal with this issue?
> >
> >D.
> >
>
>
>
> --
> darren.hague@fortybeans.com
>



-- 
Lift, the simply functional web framework http://liftweb.net
Beginning Scala http://www.apress.com/book/view/1430219890
Follow me: http://twitter.com/dpp
Git some: http://github.com/dpp

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message