I (think) I want to have a distributor app, which authenticates you and offers a main menu which sends you to another app based on your menu choice.

Each app is a separate thing related only by the user's authentication, which is why I want to separate them if possible.

My auth method involves returning a token, which my app keeps in memory and returns with each ajax request server side activity.

The problem is, if I switch apps, the token will be lost in the unload/reload of the apps, and each app will need to know the user's auth status without making them log in for each one.

Can I pass data between apps, specifically this token? I would rather not store it (even briefly) in the browser storage, but I can't see any other way. And would it really be that bad to do so? The token is just a token; it contains no data of any sort.

Thoughts gratefully received.
--
I really, really hate web programming.

squiffy wrote:

> Can I pass data between apps, specifically this token? I would rather
> not store it (even briefly) in the browser storage, but I can't see
> any other way. And would it really be that bad to do so? The token is
> just a token; it contains no data of any sort.

You can do either. One facility I have is to read the URL parameters,
and modify behaviour according to that. That part is easy, so you could
easily have your login.html page that redirects to
admin.html?token=blah and when that starts, you could have the
application remove the parameters from the URL so that the bookmark
doesn't work. However, the browser history will contain the token, and
that is why I would choose to have the token stored in the localStorage
for the transfer. Most people won't see it, and it can be deleted
pretty much immediately once read into memory. And as you say, it is a
limited life token, so if it is found you can easily check it, and if
not valid then return to the login.html page after deleting it.

FWIW, the localstorage token is how I decided to do my
re-authentication in PayPal page redirects. One off token with short
life, to allow an easy return to authenticated operation.

--

Matthew Jones

Thanks for your input, Matthew.
Unless anyone else has any ideas, I think I'll have to use the local storage if I go down this route.

Just typing aloud here ...

I was thinking between my post and your response of sending the menu selection as an ajax POST (which would include the auth token). The server would geneate aone shot token and store this against the auth token, returning the new URL and the one-shot token to the caling app.

The calling app (the menu app) would parse this in the complete event and redirect the browser to the new app, passing this redirect token as a parameter. The server can then unite this new app with the auth token and destroy the one shot token.

Problem is - how would the new app include the auth token? The app is an html wrapper around a JS file (which will be minified), so short of modifying the html which would defeat the point I couldn't "inject" the token into the app anyway.

Getting a bit rambly now. Feel free to ignore
--
I really, really hate web programming.

<< Can I pass data between apps, specifically this token? I would rather not store it (even briefly) in the browser storage, but I can't see any other way. And would it really be that bad to do so? The token is just a token; it contains no data of any sort. >>

Local storage of the token (or cookies) is really the only way to handle it without passing around the token as part of the URL (which is another option).

BTW, could you please change your signature ?  I don't like to engage in censorship, but it looks pretty odd to have such a signature when you're using EWB for building your web apps.  It kind of makes us look bad without any context.....

Tim Young
Elevate Software
www.elevatesoft.com

>> Tim Young [Elevate Software] wrote:
>> BTW, could you please change your signature ?

Done.

Thanks.

Tim Young
Elevate Software
www.elevatesoft.com

How about:

I really, really hated web programming, until i found Elevate Web Builder

Regards,
Hüseyin


On 04-01-2016 20:54, Tim Young [Elevate Software] wrote:
> Thanks.
>
> Tim Young
> Elevate Software
> www.elevatesoft.com
>

Hüseyin,

<< How about:

I really, really hated web programming, until i found Elevate Web Builder >>

That's always acceptable.

Tim Young
Elevate Software
www.elevatesoft.com

squiffy wrote:

> I was thinking between my post and your response of sending the menu
> selection as an ajax POST (which would include the auth token). The
> server would geneate aone shot token and store this against the auth
> token, returning the new URL and the one-shot token to the caling app.

I think that is going too far. The user has to log in, and you could
use the user name and password for all calls at this point, or have a
session on the server. Then you get the list of authorised applications
for that user to choose from. They choose, and the application then
asks for a token (GUID) for that application, and then redirects. The
new application wakes up, sees the token, passes it to the server
saying "hello, I'm the admin module, and this is the token" and the
server sets up a suitable session and all done (deleting the token on
the server to stop re-use).

The original auth token was the password, and it was translated to a
one-use-token as substitute.

--

Matthew Jones