The title speaks for itself. I have an application in which I need to store a password, but it must not be accessed by any user of the script, not even the developers of the application.
It is generated by the script and stored in the Script's Cache Service. I would like to know where on the web these keys are stored and if I can guarantee that no user of my application, not even it's developers, will have access to this key during the storage period until the key expires.
I didn't find anything in the documentation to tell me that.
getUserCache() will store to the user's private settings.
This page seems to explain a bit better. The user cache is private and only accessible to that user. Script cache is public.
getUserCache()
Gets the cache instance scoped to the current user and script. User caches are specific to the current user of the script. Use these to store script information that is specific to the current user.
This was also interesting.
Related
I recently noticed the addition of a "Session" object in Parse dashboard. Now, from what I understand, a session uniquely identifies a user to the server. So why would we need such a Session? For the session token? We already have a currentInstallation... so I don't really see the point. Can someone explain and provide a scenario where I would use the "Session" object. Right now they just annoy me by their presence because they take up potential space on the Parse server and I would like to go delete them all but want to make sure that isn't stupid.
The sessions are used by parse to deal with the users (is the user logged?, on which devices?, etc.), and are available as a class as you may want to manipulate them. By deleting the sessions you would automatically logout all your users, so it's a pretty bad idea.
You don't have to use or touch anything about this class, but here are few examples of why it can be useful:
[...] If a user contacts you about his or her account being compromised in your app, you can use the Data Browser, REST API, or Cloud Code to forcefully revoke user sessions using the Master Key. These new APIs also allow you build a “session manager” UI screen where your app’s users can see a list of all devices they’ve logged in with, and optionally log out of other devices. [...]
You can read more about the Sessions on their blog post.
Passport by default allows the same user to login from multiple browsers and have unique sessions created. How can I configure it to destroy the first session when the user tries to create a second session?
Currently I'm using the 'Sessions' model to add the username to the record and upon subsequent login check by username if the sessions exists. But this increases traffic to the db. I'm thinking express must be doing it already or made to, keep the 'logged in users' information in memory so that the process can be simplified. I'd be thankful for ideas around how to achieve tweak with express for this purpose or any other workaround/suggestion.
Much thanks!
I saw that at least 4 users upvote this question, so I decided to create passport-strategy for that. The new strategy called passport-one-session-per-user. It's open source strategy you can access here: https://github.com/AminaG/passport-one-session-per-user
How to use it? add it right after session. For example:
app.use(passport.session())
var passportOneSessionPerUser=require('passport-one-session-per-user')
passport.use(new passportOneSessionPerUser())
app.use(passport.authenticate('passport-one-session-per-user'))
Not need for settings, or configuration.
How it is works?
The strategy, created an array that contain serializaed user objects, and sessionID.
Every time user logged in, the strategy check if the user already logged in. If so, it's flag the other session. The next time the user in the other session make a request, the strategy see the flag, and log the user out.
I'm thinking express must be doing it already or made to, keep the 'logged in users' information in memory so that the process can be simplified.
I believe the session model loggs the user in, and saves only that logged-in-ness in the session cookie. The server itself has no clue about who is logged in, but just checks this state in the (signed) session cookie provided by the browser.
You can write your own Passport.js strategy to handle it differently.
I need to cache my home page, this far no prob, using reverse proxy is good enough
But I also need to include the header part with standalone (ESI) , so that I can check if user is connected and show his info "hello Vincent".
The problem is that if I do so, the home page (as every page) will have to test the session, and as I use PDO storage, I can see 2 query running on MySQL for every user/page.
So I tried to add a simple "is_connected" cookie, and check for its absence to render the logged-out version without asking session, but it seems that as long as I have a firewall letting anonymous user it will ask for session.
I'm running out of idea, I'd like to see what people do for this, the goal is no query at all on home page.
thanks
The home page does not need to test the session. It should be publicly cached and contain the esi include tag:
<esi:include src="/home/header_fragment.html" />
Only the header_fragment resource needs to test the user's session for login. You can store a small cache of the logged in user's information (name, email, whatever) in a signed cookie and read that in header_fragment to determine logged in vs. logged out, and if logged in display the user's name instead of looking up the information in the data store.
Background story: We run a website with thousands of users and a handful of admins. Some of these admins don't need all-access to the website, so I want to restrict their access by giving them individual permissions.
My plan is to set a Session on user login with the users perimissions, if given any. However, I'm concerned that this might be an unsafe action.
Can a Session be manipulated by a user client side? In this case a regular user could gain access to the admin features if they knew the permission names and set a Session for themselves.
I found some related questions on Stackoverflow, but they didn't give give me enough information on the subject.
You are already providing the login for admins and users so save type of permission they have and give them rights to modify data according that..And as long as your session state is encrypted it is very hard to manipulate on client side.
If you have concern about security of your existing session and cookies here is link to make it secure.
Secure your Session
This is full Article how to make your session and cookies secure...
You can indeed store server variables such as the user-agent, the ip address and so forth (and even JavaScript variables), but they are only good for validating that the persistent cookie data matches the client's new connection. The ip address isn't a good idea except when you know that the client (like you only) isn't going to change on every page load (a la AOL).
Modern web browsers and 3rd party services like LastPass can store login credentials that only require a key press (and sometimes not even that) to send the data to the login form. Persistent cookies are only good for those people who refuse to use what's available otherwise. In the end, persistent, non-session cookies are not really required anymore.
There is no such thing as secure cookie UNLESS it's transmitted over SSL only. It can be mitigated some when using a persistent non-session cookie (like remember me), by doing exactly what you're doing, but not in the same way you're thinking of doing it.
Here's the issue at hand: I have developed an ASP.NET MVC3 application using Razor. I have also implemented a custom membership provider and overridden the ValidateUser() method. Within, I query my db and get a lot of user information in addition to the password auth.
At the moment, I am pushing this information, i.e. companyId, to static properties of a class. This works and I can display/use this information throughout my app. The problem arises when a user closes their browser tab. Upon re-opening the app, the user is authenticated via a cookie, so they don't need to re-login; however, those static variables are blown away.
So guys and girls, how would/do you conquer this issue? Should I append the extra info to the session cookie? Or perhaps a better solution?
Use the ProfileProvider in ASP.NET.
For application level variables, they are going to be subject to application pool recycles and similar "simulated" restarts related to users starting all over. These variables should be completely independent of user usage and should be able to be recreated easily. If you have variables that are user dependent or that can't be restored easily without some sort of outside intervention then you will definitely need a different method of storage.
If the data is user specific, storing it in the session cookie is probably the best idea. If the data is user-related but branches multiple users it should be stored in a database or a flat file somewhere. If the data has nothing to do with users specifically then it should just be in a database or configuration file.