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.
Related
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.
I'm a nowise in ZF2 and need an advise from more experienced users.
I'm developing a small shop I want to make different lifetime for session storage and cookies.
For example when user logins server sends a cookie with 3 months lifetime and creates session storage record (for user data) with lifetime 30 minutes. Having cookie and unique session record user can buy goods, comment, and view their profile with secure data (e.g. credit card number, phone, etc).
After 30 minutes of no activity session record must be deleted but cookie must be left (cookies lifetime must be 3 months). Having only cookie user can make comments but can not buy anything or view his/her profile.
So my I'm interesting how can I realize it with ZF2 ? - As I understood "remember_me_time" must be equal to "cookie_lifetime" or they can be changed to different values ?
Does ZF2 have any standard mechanism to delete a session storage after some time for single user or I have to create such mechanism by myself ?
If you're using ZfcUser (and if you're doing user authentication on ZF2 you should be) check out the GoalioRememberMe(https://github.com/goalio/GoalioRememberMe) module, it does exactly what you're looking for (Caveat: I've never actually used it myself so I can't vouch for it's efficacy or security)
I also suggest reading this response by Anthony Ferrara (#ircmaxell) to a somewhat similar question. It contains some background information on what you should and shouldn't do, and the gist of it is: don't try to keep the PHP session open that long, use a "remember me" cookie instead and build a new session from the remember-me cookie for visitors that don't have an active session.
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 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...