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...
Related
Recently I got person ask me why our website doesn't work without cookies. My explanation is we need to save tokens and some reference in cookie, So that later on we can use it to make requests and there is limit options that we can use to save data in browser. But he doesn't satisfied with my answer and I also think there is a few options that we can make it work instead of using cookies/localStorage/sessionStorage.
My question is why most of the website cannot work without cookies? Can we make the website works without any storage in the browser?
Using cookies allows your website to remember the user (e.g. last login, avoiding having to login again) and offer corresponding benefits to them and you (e.g. tracking usage/interest, advertising). If you don't want these benefits then of course you can deliver a website which doesn't use cookies. If the website needs a login they will have to login on every different page viewed.
apologies if this has been asked but I'm trying to figure out this kind of stuff for the first time -
I'm developing an app where I want to divide the authenticated content from the web-facing side, completely; therefore I am not using a simple backbone.js-style "keep all views in one file" (unless I'm wrong about this, please illuminate!) but actually divided server files (using PHP).
Current flow: the user logs in client-side (using the Parse.com Todo app as an example) and, if successful, I store cookie (via POST/AJAX) with user email and the returned sessionToken on client side. I then thought that when user next visits site, the server can read cookie and shuffle the user to the private/locked portion of site, which, again, is a different set of PHP files.
Here I get lost -- how do I then tell Parse.com that the user is logged in, if I don't have her username/password (only email), and start grabbing data from the classes? Is there a way to do this that I'm not recognizing? I guess I can load different .JS files, read if a session exists, and JS-redirect to a different url, but that seems to me to be a weird way of going about it.
Is there a general philosophy/methodology to my questions that I should read up on, along concrete advice dealing with Parse.com questions?
I believe the Parse User session management functions should be good for you.
Check out https://parse.com/docs/cloud_code_guide#webapp-users
There is an example at the bottom of their announcement blog post here: http://blog.parse.com/2013/09/04/new-cloud-modules-for-images-and-users/
It gives you user session management with minimal effort.
I'm building a basic login script from a book that uses sessions to manage wether a user is logged in or not.
This is great, but when I close my browser, and then reopen it, I have to log back in.
Whereas, with Facebook for example, I remained logged in, even if I have closed my browser. I'm guessing this is done using cookies. Is it safe to use cookies? How long should this cookie last? Sometimes websites explicitly say, "please remember to log out at the end of your visit". Why would this be necessary?
Currently my script is kinda like this:
session_start();
if (is_set($_POST["login_button_pressed"])){
if (form_verified_successfully()){
$user_details = get_user_details_from_database();
$_SESSION['username'] = $user_details['username'];
}
}
Would it be easy to modify the above to work with cookies? And if so, how?
Thanks
A cookie is a small text file that is saved to a temporary directory on the user's harddrive. This cookie can be accessed by the browser that placed it there. It can hold data such as previously visited URLs (posts the user read vs hasn't read), the user's credentials or even the contents of the users cart or a post they didn't finish writing in a forum. You will choose how long the cookie is valid for that system, most common that I have seen are 24 hours, 7 days, 14 days and 30 days.
A session is attached to the actual piece of software interacting with the web server, ie, a browser, command prompt or other application. Once the browser is closed or the application is shutdown the session data will be lost.
Reasons you might want to have the user login again, the data you have granted access to is very private information that another user who grabs the computer 15 minutes later shouldn't have access to (banking, account settings) or the data you have given to the user is time sensitive and you want to force the user to sign in again and be given fresh data when they come back.
Most social networking sites like Facebook, LinkedIn, Google+, Twitter and several other forums and blogs will give you a cookie to let you stay logged in for up to a month or longer so you can easily come back and look through the site and post to your profile. However, if you go to change your account settings they will prompt you to login again and will only give you access to those pieces of the site during your current session. This is for security reasons.
I hope this helps out. For a quick reference, run a Google search on sessions vs cookies. You should be able to find a relevant article to whatever language/platform you are using. There are great articles out there for PHP, Java, .net and others that discuss advantages, disadvantages and best practices.
Changing to a cookie:
As for your last question, it shouldn't be very hard to change to using a cookie. Most likely it will be referenced via _COOKIE instead of _SESSION, but you will have to tell the cookie what information to hold and how long to stay active. A quick Google search for setting cookie [language] should provide plenty of tutorials. Replace [language] with either PHP, Java, Spring, .net, etc.
I was wondering if it ever would make sense to have two concurrent sessions in the same browser? There could be two types of cases with this:
1) A user opens a browser window and logs in as user A, starting session 1. Then he opens another browser window (in the same browser) where he logs in as user A, but starts a different session, session 2.
I know that this is often not possible in many browsers, as one session cookie is set for the entire browser. However, in some browsers, it is possible to have multiple sessions in that manner.
2) This is similar to 1, except that the second time the user logs in, he logs in as user B, starting session 2. So now you have a person logged in as two users in the same browser.
Finally, allowing these things doesn't seem like the best security practice and neither does it seem to be practical. What do others think?
First thing First as the your Assumption is wrong. First of all you have to understand that when Single website is accessed from browser have single session and its not possible to simultaneously run different session of same web Browser.
It seems you have wrongly understand the working of Private Browser. Private Session are not made not to share information cookies and data with other public session and vise versa also. As soon as you close the Private Session all the Cache, Cookie and other things are deleted for forever.
I have not seen any web browser supporting the Multiple session of browser.
But an alternative approach is available i.e you have to create different Web Browser Profiles which can help you as each Profile data is maintained separately and have no conflict with other sessions.
One possible scenario currently I am facing requires allowing multiple user sessions from the same browser and I have not been able to find a proper solution for it yet.
We are using Yii framework. Currently we have two kinds of users i.e customers and admins. Both login from the same login form and use same session name and variables to store session information. Only based on type column in user table(customer or admin), the user is taken to appropriate views. In one of admin views(pages), there is an option for admin to log in as any of the users and propagate through the user's view in an iframe. The problem is that when the admin open two tabs and logs in as two different users, the session information of one overwrites the other and we start getting session related issues.
Can anyone suggest me a proper way to handle these kind of issues. I have searched a lot on trying to handle this with multiple sessions, but have not been able to find a proper solution yet.
There's nothing to "provide support for" here. One browser cannot hold more than one session, since it only holds one unique cookie per site, regardless of window. If a browser actually has a mode in which it supports holding two separate identical cookies per site, then it's the same as if the user logged on from another browser or another machine. That certainly should work; i.e. you should not try to subvert that behavior. A double session inside the same browser is then just a specific instance of this multi-session behavior, nothing special.
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.