I'm regularly releasing a Google Appengine application through the command line utility appcfg.sh/appcfg.cmd. Unfortunately, the cookie that stores my password has a short expiration time; a week or less. Is it possible to extend this period?
Why not use an OAuth2 token instead of using password based authentication?
It is more convenient and can be permanently stored, no more typing passwords!
Related
I have a requirement where I need to communicate with Snowflake Sql-Api in the back-end from my application. As I come across the snowflake sql-api documentation, it supports authentication using either oauth access token or JWT token generated with keyvaluepair. For this, I am having a configuration property in my application to configure the access token with customer in properties file.
However, I see that oauth token generated has maximum expire period of 10 minutes and JWT token has maximum expire period of 60 minutes. In our use-case having the shorter expiry period is not feasible as user can't change the properties file regularly and restart my application.
I would like to know what is the way to have access token configured with long expiry period like 30/90 days etc or the way I can communicate with snowflake sql-api as per my use case.
Looking forward to hear from you.
Thanking you in advance.
Context
Developing a platform with contents and some files. Users can create a resource, and set it:
private: only accessible for him
protected: accessible via a password that can expire
public: no security rules to access
Problem
Considering we have that 2 tables:
We want to protect our element table if visibility = 'protected'. So creator should give a password for resource access, and set an expiration date.
Users can set many passwords with a different expiration date.
How can we store that password, with security, and thinking about the user can share a password, close password access, and get his password access to share resources when he needs them.
We talk here about a conception of the solution, don't care about languages or orm.
Potential solution
Cron job
Create a table joining passwords with entities, and when the user sets a password, launch a cron job that will set an attribute like active to false when the expiration date is reached.
Problem: making our app stateful, if cloud-based and the pod crash, cron job fell in void...
Store it in base64
To allow users to get back already set passwords, we have to get symmetric encryption algorithm to encrypt and decrypt the password, but that exposes resources if the database is compromised..
Also creating a table joining passwords with entities here.
No more ideas for the moment... How would you do ?
The best solution should be stateless and don't store passwords in clear.
I can think of other two solutions
A PubSub mechanism, which you can choose to trigger when to execute. For example, when you create a password today and want it to expire tomorrow. you can create a pubsub task that will trigger in a day. The task will remove that password.
A JWT token, which is a token that encoded the information in there, which includes the expiration date. When you verify that token, you will verify the signature to make sure it is not tampered and also if it is still valid. If you need to store secret inside it, you can use RS256.
I am working on an app using NativeScript and am using Microsoft OAuth2 to authenticate the user, send emails and access SharePoint with it. My problem is that the authentication token I get expires after 1 hour so the user has to login again over and over. A temporary solution I am using is refresh_token which lasts longer (I believe 14 days by default and up to 90 days) but still that is not what I would like. My ideal solution would be an option to stay signed in but it does not seem to exist at this moment.
I have read this page https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-token-session-sso and am not sure how to extend the lifetime of my token. If I can extend it at least for a year or six months, that would be great but I don't know how to do it.
My app is not registered in Azure but in apps.dev.microsoft.com and I have looked in the manifest but haven't found anything I could write to change the token type or its lifetime.
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.
I am looking for a way for two Google Apps applications to talk to each other and share data between each other. I have the following scenario:
Application A logs user in using Google Apps login
Application B logs user in using Google Apps login
then these applications need to communicate directly to each other (server-to-server) using some APIs
The question is: how do these applications verify that the other one is logged in with the same user to Google? I would imagine something like:
- Application A gets some 'token' from Google and sends it to Application B
- Application B verifies that this token is valid for the same Google account as it is logged in with
Is there a way to accomplish that via Google Federated Login? I am talking about Hybrid protocol here.
Here's a simple way to do it:
You keep everything keyed to the user's Google userid on both applications.
You share the data using HTTP requests that contain the userid.
To prevent leaking of the userids (forbidden by the account API) and to verify the messages really come from the other application, you encrypt the requests with a symmetric cipher such as AES or Blowfish or whatever you like. Both applications have the same key embedded.
You could public key cryptography. With just two applications, it's not worth it in my opinion. If you start having more apps, public key makes sense.
The fine print: encryption does not guarantee integrity or origin without additional measures. You need to take precautions against playback, for example by incorporating a time-stamp or sequence number. You need to take precautions against tampering, e.g. with a checksum. Make sure to use CBC and good initialization vectors. Keep the key secret.
user.user_id() is always the same across all the apps for the same user. So you can simply compare values returned by user.user_id(). Is this what you are looking for?
Note: Every user has the same user ID
for all App Engine applications. If
your app uses the user ID in public
data, such as by including it in a URL
parameter, you should use a hash
algorithm with a "salt" value added to
obscure the ID. Exposing raw IDs could
allow someone to associate a user's
activity in one app with that in
another, or get the user's email
address by coercing the user to sign
in to another app.
From docs