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.
Related
I have a URL "www.anothersite.com/login" in "www.mysite.com". When a visitor clicks the URL, it should go to "www.anothersite.com/login"'s login page and should automatically fill the "username" and "password" field which i give in backend script. Hence the user should just click "Login" button.
I tried using cURL, but no use. It just redirects to "www.anothersite.com/login" page but not filling credential fields and not even autofocussing the field.
Or If there's any joomla plugin to perform this action please post it.
What you are describing is Cross-Site scripting and is FORBIDDEN.
You can not run a script on a page you don't control because you could steal the user's username or password or other such bad things. All modern browsers prevent this from happening.
This is the most obvious application of cross site scripting. For more information on the clever and subtle ways in which attackers have historically tried to do such things, you should check out OWASP
The only other way I can think of supporting this functionality is if the site supported passing those parameters in a query string for the URL, but that would also be an extremely bad idea.
User's browsers can store this information if the user wishes to have things autofilled, and you should not be passing passwords back and forth after login. You certainly should not be storing user credentials in such a way that they can be retrieved in their original form after the user has logged in.
Joomla won't store cleartext passwords by default, and for good reason.
If the external site supports delegation, you might be able to use OpenID or oauth. There are plenty of examples of how to use those systems elsewhere on Stack Overflow, so you should read up on them.
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 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...
Why was this policy even created? Seems to me that there are only disadvantages of this. If you want to, there are ways to access another domain (for example, JSONP). Wouldn't it be much easier for everybody if there was no such policy?
But I suppose that the guys who created it are smart and that they did it for a reason. I'd like to know this reason.
Same Origin Policy is not primarily meant to defend against Cross Site Scripting (XSS) as stated above but to hinder Cross Site Request Forgery (CSRF).
A malicious site shall not be able to load data from other sites unless this is allowed by that other host explicitly.
E.g. When I browse www.malicious.com I would not want it to be able to access my concurrent authenticated session at www.mybank.com, request some of my data from the bank's AJAX interface and send it to malicious.com using my browser as relay.
To bypass this restriction for intended use or public information the Cross-Origin Resource Sharing (CORS) protocol has been implemented in modern browsers.
Security.
If it didn't exist, and your site accepted input from a user, I could do bad things. For example, I could put some javascript in the text I entered on your site, that did an ajax call to my domain. When anyone viewed my input (like on SO, when we view your question), that javascript would execute. I could look at how your website worked in my inspector, add observers to your input, and steal your users' data.
The same origin policy prevents me from sending your data to my domain via ajax. To see how easy it is, if you have a simple website, just put the following in one of your forms and submit the data.
javascript:alert(document.cookie);
If you don't take steps to do something about that (your framework might automatically), I just injected javascript into your site, and when someone views it it will execute. (It's called javascript injection)
Now imagine I got a little more creative and added some ajax code....
The browser needs to prevent such things or using the web would be digital suicide.
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.