esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Hirsch, Richard" <>
Subject AW: Token Problem in browser-based clients
Date Wed, 04 Feb 2009 09:13:00 GMT
Good idea. We were trying to mix a java-based ESME bot (which filtered ESME messages) and a
JavaScript client. We are now separating the two and creating a pure JavaScript client using
your idea.


-----Urspr√ľngliche Nachricht-----
Von: Darren Hague [] 
Gesendet: Mittwoch, 04. Februar 2009 09:53
Betreff: RE: Token Problem in browser-based clients

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...


>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 -
>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?


View raw message