In my app, I have to serve huge secure files ( svg drawings etc ) that I want to show only to logged in user. File do not change much, and if it does, It do have different url, so I would like to use edge cache on google app engine for faster loading to already logged in user.
My question is, how do I make it secure ? i.e. if the user logged out and if someone else use his browser can he see that content ? if so, how do I prevent it ?
Related: How do I prevent browser from remembering a url of a content on my website.
One of the solutions could be using Google Cloud Storage with ACL, i.e. in the way that only a particular logged in user has access to that file. This solution is limited to Google Accounts though.
UPDATE: Google Cloud Storage now has a short-life signed URLs:
"...you could provide a signed URL to a user which would allow the user to access that resource for a limited time. Anyone who knows the URL can access the resource for a limited time. (You specify the expiration time in the query string to be signed.)"
- so, that could be even closer to what you need.
Another solution is that you serve your huge file from your dynamic handlers. This however will consume a lot of CPU and bandwidth. Also, you'll still be limited by GAE quotas.
Related: you can't prevent browser from remembering visited URLs or any other kind of history. It depends solely on the specific browser and user preferences (not accessible to your app / javascript/whatever). The only thing you can ask your users is to clear their history, cookie and whatnot when they log out.
You could set expiration in the appconfig
Sorry I just have a german link (just try, maybe google switches to your language)
http://code.google.com/intl/de-DE/appengine/docs/java/config/appconfig.html
As long as not expired the browser could cache the file locally. This results in a small load time. However, if the cache is too small, the browser will request the file again.
A good browser will only make secured file to the logged user available.
However, you have no guarantee which browser is in use. Your user could always download secure file and publish them anywhere.
When a user give the login to third users, they could all the time access the secured files.
I don't think you could avoid to remember any links. In some way it is a contradiction to the above.
Related
I'm looking for some information about a problem that I never thought about, and that I can't find much on the internet (or I'm looking wrong).
Here it is, for a dashboard project in my company, I need to be able to set up a system to store one account per client, or I just have to click on the account in question to connect, like twitter, google or instagram for example.
After the person has added his account, it appears in a list that can switch whenever he wants. Only I don't really see how to set this up, storing the login information in the localStorage? or the jwt token? I confess that I can't find a correct and secure solution as it should be, that's why I'd like to know if some people would have already done that, or if I can be oriented on an interesting solution?
Thanks a lot!
(Sorry for my english, i'm french and it's not perfect ^^)
Do not use localStorage. LocalStorage is not secure at all and can easily be hijacked through any js code running. If you need to store sensitive information, you should always use a server side session.
When a user logs into your website, create a session identifier for them and store it in a cryptographically signed cookie. If you're using a web framework, look up “how to create a user session using cookies” and follow that guide.
Make sure that whatever cookie library your web framework uses is setting the httpOnly cookie flag. This flag makes it impossible for a browser to read any cookies, which is required in order to safely use server-side sessions with cookies. Read Jeff Atwood's article for more information. He's the man.
Make sure that your cookie library also sets the SameSite=strict cookie flag (to prevent CSRF attacks), as well as the secure=true flag (to ensure cookies can only be set over an encrypted connection).
Each time a user makes a request to your site, use their session ID (extracted from the cookie they send to you) to retrieve their account details from either a database or a cache (depending on how large your website is)
Once you have the user's account info pulled up and verified, feel free to pull any associated sensitive data along with it
I have an ionic 1 (angularjs) app, which doesn't work offline, on first launch user creates account, logs in and next time he opens app he is already logged in.
The scenario is I am looking for is an offline mode(that is without internet connection), here if the user is not connected to internet he's not allowed to explore the app, here i want to let the user explore the app even without internet connection, with the credentials already logged in.
A lot of resources suggests to use localstorage, but i can't find any relevant resources regarding the same.
I have spent hour reading and testing different approaches but well even more confused than ever. It seems to me as such important feature of hybrid app that there should be a good implementation... Would appreciate any help/suggestions/examples/links...
My ultimate goal would be that once authorized user can access and manipulate his profile data even if in offline mode. That means that opening app allready logs him in an his profile info is stored as well.
My minimum viable goal would be that when app is opened app recognizes user, checks as logged in, redirects to logged in state and makes http to get all user details. While user is waiting for that response there are loading spinners but he can start to use logged in app experience.
Your connection windows is controlling your App. So basing on this, you can easily make a checknetwork function to make it check if you want.
If this function return "false" then you bypass the login if only the user has already logged in.
On your provider for the LogPage, you should control this kind of things with shared values as
let isOnceConnected: boolean;
Hope this help.
bro just store your token generated by the server or user data in local storage, If the user is in the local storage then redirect the page other send it to the login page,
local storage like
to set =>
localStorage.setItem('auth-token', JSON.stringify(access_token));
to get =>
JSON.parse(localStorage.getItem('auth-token'));
Also, you can use Storage plugins to store any data.
I have an angularjs app that is on a separate domain than my backend, and the users from my backend all have roles and permissions that allow them access to various areas and elements of my frontend.
Before, I was just storing to a cookie and checking as I needed through the use of angular services and whatnot, cool.
Now the permissions datum have reached the point where they are too big to store in a cookie in the browser. And I'm avoiding Localstorage for fear of user tampering.
The Question:
How do I store the users sensitive data (or anything sensitive, really) that are too big for cookies on the client side in a manner that is safe and doesn't require API calls all the time to get?
I don't want to have to phone home every page change to get this data direct from the server when I need it, because I feel this would be really detrimental to the speed and flow of the site, not to mention the frequency at which this would need to happen would be ridiculous for my app.
Keep in mind that I do proper permission checking on the backend before carrying out any actions, but I'm more concerned about users tampering with their permissions to show certain elements that were removed on the frontside before.
What would be your solution or your advice on this?
If it ends up on the user's computer, regardless of whether it's in a cookie, in local storage, in the URL, in the browser's cache, or anywhere else on the user's computer, assume that the user can see it and mess with it. (You could encrypt it, but if your client-side logic knows how to decrypt it, you're back to step one.)
The best that you can do is exactly what you've described - be sure that the server only carries out authorized actions, and never trusts what the user tells it.
I have an application deployed on GAE. It allows users to register for an account, and I use the google user id as the primary key to link to their account.
I have a registration link that should be visible if either the user has not been authenticated by google and/or they do not have an account on my site.
What I am trying to figure out is what is the best way to figure out if the user has an account on my site as they go from page to page. I have an authentication filter that is triggered on every page, and the filter looks at their google id (if they are logged in), goes off and determines if the user has an account on my site, and sets a request parameter, that I use in the jsp to determine whether or not to show the registration link.
It seems wasteful to do that every time, so I refactored it and had the authentication filter store the Key object tied to their user account on my site in a Session. If the key attribute is not null, I take that to mean that the user is registered on my site.
Does that seem logical, or are there better approaches? The complexity to me comes from the fact that the user may be logged in with google, but that doesn't necessarily mean they have an account on my site.
My question
When it comes to storing authentication data, you have two options :
Store the data in session
Store the data on client side, in a cookie typically
Storing the data in session is a perfectly valid mechanism, and that's actually the most common.
However, managing a session is costly (you need to store it). In App Engine's case the sessions are stored in the Datastore, with probably some caching. So it's still a call to the datastore.
That should be totally acceptable, however if it turns out managing a session really decreases you app's performance, you can always store the data in an encrypted cookie. That way the information is provided by the browser every time it sends an HTTP request. Note that it means you must get encryption right and that HTTP requests will be slightly bigger (the size of the encrypted data).
So in the end it's a tradeoff. I would recommend sticking to sessions unless you experience performance issues. The advantage of sessions (compared to your fist approach) is that if you ever want to store additional data, you will have less code to add.
I am working on a chrome bookmarking extension with google app engine as the backend. I am the only user now but I thought that if in the future there are other users the url needs to include the user name for the extension to interact with the backend. So I was thinking to change
http://ting-1.appspot.com/useradminpage
to
http://ting-1.appspot.com/user_name/useradminpage
where "user_name" is the gmail user id.
But I looked at twitter url and I see that they have
http://twitter.com/#!/user_name/
What is the purpose of "#!"? Is my scheme good enough in this case?
The # in a URL signifies the 'fragment identifier'. Historically this has been used to identify a part of a document identified by an 'anchor' tag, but recently webapp developers have begun to use it to pass information about the page state to Javascript code running in the page. This is used because it's possible for Javascript code to modify the fragment of the current page without causing the page to reload - meaning it can update as you browse through the webapp, and go right back to where you were when you reload the page.
The fragment is not sent to the server when the browser loads a page, so Twitter's server just sees a request for twitter.com; it's up to the Javascript code in the page to examine the fragment and determine what to do after that.
In your particular case, assuming you're using the App Engine User service to authenticate users, you have a number of options for how to distinguish users in your URLs:
Use their email address. In theory this can change, and users may not want their address in a URL they will share. If the URLs are private, this is more or less a moot point.
Use their user_id. This is opaque and reveals no useful information about the user, so it's safe, but it's also meaningless and hard to remember.
Let users pick a nickname for their URLs, like Facebook and other services do, on a first-in, first-served basis.