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.
Related
Let's suppose I'd opened two or more user sessions on two or more devices (same user with not admin privileges).
At the current session, if I log out, it means all others sessions will also close? If not, is there a way to do this by an URL request?
something like this:
User call a method, ex: [plone-site]/close-all-sessions-except-this;
Results on: all user sessions, opened on the others devices are closed.
Would be better if this method were native in plone.
gmail has this feature. I think it's an important security and privacy issue.
Not really sure what you are asking, but if you want to automatically logout all authenticated users (not only one user) you can:
Go to ZMI
Enter inside acl_users
Select the session plugin
In the "Invalidate all session identifiers" section click the "Clear secrets" button.
As you can read there:
By clicking the button below you clear all secrets used to validate
sessions. This will immediately log out all users who use session
authentication and require them to log in again.
That's a nice feature request, would you mind opening an issue? AFAIK Plone doesn't include that by default.
When you log out of one session Plone will close all sessions for that browser AND site URL, because the session is stored in a cookie set to site's domain. However Plone won't log you out from other browsers/devices, nor in the edge case you're accessing the site by IP, if that's available.
I have a website that authenticates users with the active directory. This website is made for internal company use and does not hold any sensitive information. The website is secured with SSL. When a user logs in, his/her username and password will be transmitted to the server through POST. I then store his/her username in a session cookie with a TTL of 1 day, refreshed by every single web action. From this point on, every webpage will check to see if this cookie with the username exists. If it does, it will allow users to access that certain page. Login out will just remove this cookie.
Would this way of authentication be acceptable? Is there a better way to handle user authentication? Is it necessary to use sessions instead and store session id's in cookies?
It does work out nicely to use Sessions, yes. I don't know what language you'd be using, but storing information in general locally is a good idea (this does not include sensitive and private information, ie. passwords).
Pages usually check your authentication (and its type) upon loading.
I've lost my touch with PHP, but for instance ASP.NET has a pretty neat (but complicated) Identity system where your login information would be stored in a separate Session, and destroyed upon logging off, but also stores information regarding its Type. This would later allow the developer to mark pages that would require a specific type of an Identity. For example:
[Authorize(Roles="admin")]
public ActionResult Index() {
// Your action information
}
Again, I'm rusty with PHP, but I imagine it's similar where you'd simply check the Sessions before the <html> tag, ie.
<?php
if(is_null($_SESSION["user-info"]["type"])
header("Location: index.php");
?>
<html>
...
Overall, the way you use sessions in each of the back-end web development languages could defer, but the overall usability is the same. You'd use Sessions to store User information, Store "basket" items, etc.
I am making a bookmarklet, which calls a Google App Engine app. The GAE app uses login information, which I want to store in bookmarklet, so when user first clicks bookmarklet,it asks for login info, but from next time onwards it automatically supplies it.
The difficulty of a bookmarklet directly storing data is that it can only store data in cookie or in localStore, both of which "belong" to whatever page it is currently on. That means it won't work again the next time you use it on a different page, and it also means the page you are on can access the data, which is generally very bad for security.
There are two basic ways your situation is generally handled. The two main ways are:
1.) The application used keeps the user logged in with a cookie. The login information is not stored in the cookie; only a session ID is. This is like when you return to many popular websites, you don't have to log in again. Very often these types of bookmarklets open a small popup for the user which contains a page from the app. If the user is not logged in, the app prompts the user to login first. The bookmarklet in fact knows nothing about being signed in or not.
2.) Each bookmarklet is custom created for each person. So my bookmarklet would be different than yours. The difference is simply that mine will contain my login info in the code, and yours will contain your login information in the code. In fact we would each have to login to the app first before we can get our own personalized bookmarklet.
Generally, option 1 is better and easier and more secure.
If I understand it correctly,this Might help you. http://ajaxian.com/archives/whats-in-a-windowname
It allows for storing data in windowname in JS. Allowing for access of up-to 2 MB of data (A lot more than cookies can hold) and I believe can be used across tabs...
I am wanting to build an admin tool where I can "impersonate" users of my site, without having to lose my session as an admin.
I would like to be able to open an iframe that will view the website "as the user", without changing the state of the page that opened the iframe.
Is that possible? Is there a better way to do this?
It's possible, but there's a bit "but" :)
Just a couple options to start with:
Use URL-based session tokens (as Java Servlets do when you have cookies disabled)
Use different domains for "normal" site and admin interface
iframe itself won't help you much: it will always share its cookies with the browser. So in order to avoid that, you can use either of the above options—but that does not depend on the iframe.
What language? My answer is based on the assumption that PHP is your chosen language.
Firstly, I would say you have planned your application wrong if session impersonation is the only way you can view your site as another user while still keeping your admin login intact.
One way you could do it, and again this is assuming that you are using PHP as well as the default session management functions within and you do not have a custom session handler would be to load the iframe url with the ?PHPSESSID=sessionidhere parameter.
A better way to do this is to create your site and authenticate users via a user object of sorts and then add some sort of url parameter such as ?userbrowseid=123
Then when you load the page, your code will only check if the parameter exists if you are already logged in as an admin. The page would then overwrite your current user object with the user object of the user with the id 123. Steps should be taken to make sure your session cookies are not overwridden with the impersonated user object. As this would be in an iframe, your site will work as an admin and the iframe will be loaded as the user object.
I'm currently making a site using GWT, being hosted on AppEngine. I'm making it with my own logins that I'm making (I know Google provides something with GWT, but I need my own login system), and I've been trying to figure out sessions for quite a while now. I've found a few tutorials, and one of the sites that I was reading is http://code.google.com/p/google-web-toolkit-incubator/wiki/LoginSecurityFAQ
There is a section there on "How to Remember Logins". I know how to get the session ID and store it on the client in a cookie through an RPC call. What I don't understand is, eventually after a day or so, the user comes back and I'm supposed to get the session ID from the cookie and send it back to the server. What am I supposed to do on the server in order to securely evaluate if session ID is still legal, and pull up all the necessary information about the user?
Additional questions:
1. What would make the session ID change?
2. What if the user was on a laptop, and the user went somewhere else. Would he still be able to be securely logged back in without having to type in his login and password again?
Thanks!
~Scott
Similar question: question on GWT, Cookies and webpage directing.
One important thing you should remember: don't rely on cookies alone - transfer the session ID/token in the payload of the request too and compare it with the cookie value on the server side. This will prevent XSRF attacks. That's the sort of thing you should be worried about.
The policy on how to deal with session IDs depends on how seriously you take security in your application and what type of application is it. For example, you can login with the same token on GMail from different IPs - I presume they allowed this because it's common that the user's IP changes over sessions. They did however add a feature that allows you to see from which IPs the user logged in recently. And don't forget about users with dynamic IPs (quite a large number) - if you keep track of tokens and IPs you will basically disallow those users to be kept logged in between sessions.
What am I supposed to do on the server
in order to securely evaluate if
session ID is still legal, and pull up
all the necessary information about
the user?
You should keep track of the session IDs/login pairs in your DB.
What would make the session ID change?
Either it expires or the user tries to log in with a token that is not bound to their IP. You could add your own rules too - like the number of logins, etc. For additional security, you can generate a new session ID/token on every new login/session (the user authenticates with the old token, the server checks that it's valid and sends back the user the new token he/she should use from now on).
To remember logins you need to securely generate a unique session id. Normally, this is placed in a cookie. I would recommend using a framework that does session cookies for you. Getting it wrong can leave your site wide open to abuse. Things to consider include:
Do you need to worry about cookie stealing. The user's IP address should be encoded in the session id, or linked to the session id. Check the IP address on every page access.
Ensure your logins are on encrypted sessions. Otherwise, you expose credentials in plaintext on the network.
How long should sessions last. They should time out after a fixed time limit. This can be hours or days long.
Remember me should be different functionality on a different cookie. It needs to contain something that can be used to indentify the user. Depending on your security requirments it may need to be an encrypted value. This cookie can have a longer timeout.
Answers to your additional questions are.
Nothing on the client side is likely to change the session id. The session id should be regenerated every login.
Depending on how secure the session id is, they may have to login. Secure session cookies often encode the IP address to prevent cookie stealing. If so, the laptop user would need to login again.