Why should response caching be disabled for authenticated clients - caching

I am currently working on a website which provides a personalized timetable for each employee in a specific company, this timetable will internally update every five minutes. When opening the website you can just use a normal pager to look at all of the weeks.
At some point I noticed that the user behaviour shows, that people click between weeks a lot and visit the same page (of the pager) multiple times in even a minutes. I thought it would be a good idea to cache this individual pages for lets say 2,5 minutes.
Since this web app is powered by ASP.Net Core, I visited the MSDN about caching which states the following:
Disable caching for content that contains information for authenticated clients. Caching should only be enabled for content that doesn't change based on a user's identity or whether a user is signed in.
I know that this is just a warning, but why is there the need of a warning? Is there any reason why this would be bad, besides the fact that specific data could be 'out dated'?

I found the answer the question with the help of #Eilon, who linked me to this GitHub issue. Which provides a simple example. In a few words, it is all about, that a different authenticated user could possibly get a cached response which contains information about another authenticated user. Since this can be controlled and sometimes it won't even matter, it is only a warning in the MSDN.

Related

Google Analytics - PageView vs Sessions

I have simple question for my case. I have one HTML page on router witch serve as hotspot page. Also I have setup Analytics on that HTML page.
Question is when I want to deliver to a client number of users that visited that hotspot page, what should I use - PageViews or Sessions.
I notice that I have big difference between those two options.
example:
Sessions for 3 months: 1,050
PageViews for 3 moths: 15,501
Note: I only have one page on that hotspot..its not multi page its only one. Thanks
In GA, there's Users, Sessions, and Pageviews.
1 A user can have many sessions, 1 session can have many pageviews.
Out of the box, a user is defined by the cookie that's stored in the browser. If the cookie is deleted or of this physical user uses another browser, from GA's perspective it is a different user.
Sessions are started when a user visits your site and if their last "hit" sent to GA hasn't been over 30mins. The same thing with the cookie applies here. New session if the cookie is deleted (there are other cases where a new session will start, but for basics, you don't need to worry about them).
Pageviews are just that, every time someone views a page on your site, this count will increase. This will count refreshes, revisits, etc. There is also "unique pageviews" which only increment once per session.
Now, going back to which one you should use. Sessions or Pageviews won't tell you about users. Sessions will tell you how often people visit your site. Pageviews will tell you how often the page is loaded. If you want to tell users, you need to look at the users metric. Though do note the thing about cookies and cross devices.
If your site is authenticated, it is much easier to track individual accounts by utilizing the userID feature in GA.

Reconciling browser-side and server-side authentication

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.

Using Cookies versus Sessions for login

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.

store data for bookmarklet

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...

Timeout on custom membership provider in asp.net 4.0

I have implemented custom membership provider in my project. i kept one flag on database to get the users online. i want to reset this flag on the log out, i can do this if the user log out properly . I have to reset the flag on database even if the the browser closed directly or on any machine failure or normal time out, any tricks on membership provider to solve this. experts am waiting for your answers!!!!!!!
Thanks.
just put a field for users like IS_LOGOUT_BUTTON_PRESSED typeof(bool) default false
if the user click LogOut set it TRUE.
if the user closes browser, it will stay false. Then you can see what user did.
I am afraid that you are tilting against windmills.
You will notice that the sql providers implement the 'users online' by simply updating last activity in most all provider methods (and subsequently the stored procedures) and then using a predefined 'online time window' to determine if the user may still be online.
To implement an authoritative 'is_online' flag would require that you have complete control over the user's means of starting a session and ending a session, which you do not and can not do due to both the nature of the browser ui and the way that sessions and ticket expirations are bumped.
So you can never really be sure whether a user is online or not, rendering any efforts you have made to track this metric unreliable.
And unreliable data is often of less value than no data at all.
I am quite certain that you will find nothing but frustration in attempting to apply an absolute, as described in your question, to the stateless and freeform nature of sessions and tickets.
Sorry I have not better news.

Resources