Login ProductsSalesSupportDownloadsAbout |
Home » Technical Support » Elevate Web Builder Technical Support » Support Forums » Elevate Web Builder General » View Thread |
Messages 1 to 9 of 9 total |
One App To Serve Them All... |
Mon, Jan 4 2016 10:57 AM | Permanent Link |
squiffy Telemix Ltd. | 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. |
Mon, Jan 4 2016 11:27 AM | Permanent Link |
Matthew Jones | 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 |
Mon, Jan 4 2016 11:54 AM | Permanent Link |
squiffy Telemix Ltd. | 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. |
Mon, Jan 4 2016 2:43 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | << 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 |
Mon, Jan 4 2016 2:47 PM | Permanent Link |
squiffy Telemix Ltd. | >> Tim Young [Elevate Software] wrote:
>> BTW, could you please change your signature ? Done. |
Mon, Jan 4 2016 2:54 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@elevatesoft.com | |
Mon, Jan 4 2016 3:04 PM | Permanent Link |
Huseyin Aliz myBiss ApS | 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 > |
Mon, Jan 4 2016 4:15 PM | Permanent Link |
Tim Young [Elevate Software] Elevate Software, Inc. timyoung@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 |
Tue, Jan 5 2016 5:56 AM | Permanent Link |
Matthew Jones | 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 |
This web page was last updated on Friday, November 1, 2024 at 07:01 PM | Privacy PolicySite Map © 2024 Elevate Software, Inc. All Rights Reserved Questions or comments ? E-mail us at info@elevatesoft.com |