Hi Tim,

Being used to PHP where code is executed on the server and served up as HTML on the browser, I was wondering about security in regards to Javascript considering that it's executed on the browser side.

Obviously embedding passwords in EWB apps would be a bad idea, but most databases require a username and password for the connection.  How would this be implemented? Would this be stored in a file on the server end that is read by EWB?

Steve,

EWB generates Javascript so security is same as other JS based solutions - there are number of options available but i'be only used 2 myself:

Simplest way to secure is to have web server do the auth for you - basically have EWB files in server folder that requires login. You would need a login page that is now EWB for this (e.g. gmail).

If you want to handle login in EWB then one option for example is to write a user auth web service that takes username/password as params and returns a token. Then have EWB include that token in other web requests (so you don't have to keep sending username/password every time).

Obviously in both cases this should happen over SSL link to avoid sending everything in plain-text.

Raul

Hi Raul,

<< Simplest way to secure is to have web server do the auth for you - basically have EWB files in server folder that requires login. You would need a login page that is now EWB for this (e.g. gmail). >>

Thanks for the suggestion, and no offence, but I think that's a very clunky way of doing it.

<< If you want to handle login in EWB then one option for example is to write a user auth web service that takes username/password as params and returns a token. Then have EWB include that token in other web requests (so you don't have to keep sending username/password every time).  >>

Yeah, I was thinking along similar lines.  I will probably just pass the user details to a PHP backend app which would do all of the authenication and pass back a session token.  Just thought I'd throw this question out there to see what others are planning to do, and to see if Tim has any ideas I hadn't thought of.

Thanks for your suggestions.

Steve

<<
Thanks for the suggestion, and no offence, but I think that's a very clunky way of doing it.
>>

No offence taken and i agree it's bit clunky but it is simple and you can always just protect the web services side of it. The ServerRequest allows to specify username/password so this in theory should work right out of the box.


<< I will probably just pass the user details to a PHP backend app which would do all of the authenication and pass back a session token.  >>
I prefer that as well as one can encode additional info into the token easily. Also doing a digest type auth where you do challenge./response and hash the password would protect the actual password itself.

<< Just thought I'd throw this question out there to see what others are planning to do, and to see if Tim has any ideas I hadn't thought of.>>

I'm interested in hearing of other options as well.

Raul

Steve,

<< Yeah, I was thinking along similar lines.  I will probably just pass the
user details to a PHP backend app which would do all of the authenication
and pass back a session token.  Just thought I'd throw this question out
there to see what others are planning to do, and to see if Tim has any ideas
I hadn't thought of. >>

That would be my suggestion also.  The bottom line is that the web server
app *has* to handle the authentication, and the web browser side is simply
at the mercy of the web server.  The good thing, however, is that EWB allows
you to cleanly separate the two parts so that you're only requiring
authentication for actual data sent over, not for UI formatting/elements.
This keeps things nice and fast and makes an SSL connection much easier to
deal with.

--
Tim Young
Elevate Software
www.elevatesoft.com