cancel
Showing results for 
Search instead for 
Did you mean: 

Signing in each and every visit?

Moderator
Moderator

Re: Signing in each and every visit?

OK, thanks for the updates!

 

Thanks,
Liz

Did my post answer your question? Accept as Solution to help others find it faster.--------------------------------->

Highlighted
Sophomore

Re: Signing in each and every visit?

What I don't understand is why my avatar is showing in the upper right corner but I still have to sign in Smiley Surprised  Now that's not the case ALL the time.  Sometimes I see the orange "sign in/register" link but most often my granddaughter's photo is there which I would assume means I'm logged in but if I try to post to the community, I still have to sign in.

Sophomore

Re: Signing in each and every visit?

@monicakm

I am the kind of person who finds this stuff very interesting, and your question of why your photo (avatar) shows up even when you still have to log in got me wondering. I decided to do some poking around to see why this occurs, spurred on by a lack of anything else to do tonight.

 

I found that the reason your avatar shows when you return to the site is due to the way these forums handle cookies. More specifically, how the cookies are handled between the Hughesnet community, Mixpanel, and Lithium. In case you don't know, Lithium is the company which makes the backbone/infastructure of this community forum. (In my opinion hughes made a great choice in going with their service.) Mixpanel is a business analytics company, which handles the... analytics. I'm not sure what gets sent to them, but to be honest I really don't care. I'm not interesting enough to be worth anything analytically.

 

This website is broken down into two main frames. The top blue bar (the one with the orange sign in button) is coming from header.hughesnet. The rest of the page is coming from community.hughesnet. It seems the header is shared amongst all hughesnet pages, while community is for these forums only.

 

Here is a screenshot of the cookies used while not logged in and navigating the community pages:While browsing before logging inWhile browsing before logging in

 As you notice, I whited out the values of each cookie, as they contain personal information. I'm not entirely sure if the rest of what I whited out is personal, but I'm sticking to a better-safe-than-sorry mentality.

 

At the top there are two LiSESSIONID entires. These are both IDs unique to that browsing session. Those cookies are set to be deleted once you close the browser. They have nothing to do with login status. I have seen cookies used like this before, and they were simply used to make sure the content you request is sent to the correct person. The online game distributer Steam had an issue with this feature (not in cookie form, but the same general concept) where when people sent a request for the store page, they were sent someone else's store page, as if they were signed in as the other user. But since this value isn't used for login information, you could not affect the other user's information at all. (Tangent over...)

 

Then we have two LithiumVisitor entries. To be honest I have no idea what these are for. They are set to expire in 10 years, but are changed in the same manor as the LisessionID entries. Someone smarter than me put them there for a reason, and I trust they know what they are doing. I'm going to put VISITOR_BEACON and lithiumLogin in the same boat, as they seem to operate the same way.

 

The last three entries are for Mixpanel, and appear to be sessionID entries for their own use. The second Mixpanel is the only entry which contains my login ID. These cookies are set to expire in a year, and they do persist across browser restarts. 

 

The following screen shot is after signing in: 

While logged inWhile logged in

 

As you can see, four cookies were created. _mpidentified, _uin,  _vsetting, and hughesLoggedIn. All four of these are boolean values (Yes/no or True/false). Interestingly, the first three either show a 1 or 0, and the hughesLoggedIn shows true. All four of these cookies are set as session cookies. 

 

Two additional cookies are created near the top. LithiumUserInfo and LithiumUserSecure. LithiumUserInfo seems to be your very own user ID number, as the value is the same amongst logins. That would make LithiumUserSecure a security key. This key is unique with each login, so you can't simply use someone else's cookie value in UserInfo to log in as them. Note that UserInfo is set to expire 2 hours after you login, while the security token is session only and should be deleted when the browser is closed. That is why you have to log back in every 2 hours that you are on these forums!

 

At this point you may be wondering when I am going to answer the question of why the avatar stays on screen even when you restart the browser and are technically logged out. I promise that is coming soon!

 

This is the state of the cookies after closing Chrome and coming back to the community forums:

After restarting browserAfter restarting browser

 So what has happened? Not quite what is expected. The only session cookie which has been deleted is hughesLoggedIn. As far as the browser knows, we are still logged in to Lithium! None of those session cookies were deleted. 

 

If you look at the top right of every screenshot, you will see a red circle with an X and a number. That is the number of errors the website encountered. Under normal browsing I am getting 5 errors. These are all related to the page trying to communicate with Mixpanel. Something is broken there. Yet another reason you shouldn't be worried about the analyitics. Smiley Happy  The extra 4 errors all point to redirect issues with Lithium. Lithium is refusing cross-origin requests. This is absolutely what should be happening, as the value being sent to Lithium for LithiumUserSecure (the security key) is not valid anymore!

 

So.. what is causing this? Why is the hughesLoggedIn cookie being deleted as intended but not the rest? 

 

It appears the hughesLoggedIn cookie is actually being deleted once you navigate back to this website, not when the browser is closed. It appears Hughesnet seems to checks this value before you are even served the webpage. The header cookie is fixed in advance. This is why you  can have your avatar show up under the orange sign in box! 

 

At this point the browser knows it is not signed in to Hughesnet, which is why the hughesnet header is working properly. BUT the browser thinks it is signed in through the Lithium service, since the cookies are still there, which is why the rest of the page looks like you are still signed in. Once you click on another link (going to the Tech Support forums, for example) the remaining session cookies should be deleted, and your avatar will no longer show. Sometimes they aren't deleted for a while, and I have no way of knowing why.

 

 

Although this is just a graphical issue, I set out to find a solution.. and I found one! For Chrome, at least...

 

In your Chrome settings, near the top, there is a setting for 'On Startup'. If this value is set to 'Continue where you left off' the deletion of session cookies can be broken. If you go all the way to the bottom you can click "Show Advanced Settings".  Scroll to the bottom again.. under System there is a check box for "Continue running background apps when Google Chrome is closed". When this setting is enabled, Chrome never really 'closes'. There is a known issue (which is an old...old issue) that this setting interrupts the deletion of session cookies. I unchecked that box and when I restarted the browser and came back here the webpage looked like I had never signed in before. 

 

Your mileage may vary, though, as I tried this on two different computers and got two different results...

 

TL;DR: Cookies are the reason.

Teaching Assistant

Re: Signing in each and every visit?

@Matt_Is_My_Name, excellent post.

Sophomore

Re: Signing in each and every visit?

Wow!  I'm impressed and flattered (even tho you did say you were bored LOL) that you went to all that trouble, but, I have a feeling it was fun for you Smiley Happy  And THANK YOU for letting me know that the first half of your message didn't include the reason for the avatar remaining when I'm not logged in.  I was feeling pretty stupid!   So I kinda sorta understand (but not really)  what you described, but I wonder WHY (they) decided to set it up like they did.  I've never run across this in over 20 years of signing into forums.  Not a bid deal tho.  I do prefer the forums that let me stay logged in Smiley Happy

Sophomore

Re: Signing in each and every visit?

I'm pretty sure it is because you aren't just signing in to the forums, you are signing in to your Hughesnet account. Reading through some previous posts it seems like the logins are being handled like this because of some company policy.

 

I do agree, though, that I prefer to stay signed in.. but it's not like signing in is really a hastle!

Moderator
Moderator

Re: Signing in each and every visit?

Hi folks,

 

Thank you for your patience, while we finally got an explanation for the likely reason for the more frequent logouts:

 

Once a user has authenticated within the community it is largely controlled by the LiSESSIONID cookie. This cookie is considered a session cookie, so whenever someone closes their browser it is removed per the standard session cookie policies. When this cookie is removed due to the browser being closed you should find that you are logged out the next time you visit the community and will have to log in again. 

 

This may also explain why this happens when users are closing their browser tabs depending on how their browser is configured, as browsers can be configured to delete cookies when a tab is closed. 

 

Sessions will also automatically expire on their own within a community, which should be 2 hours for the HughesNet community (note: this is assuming the user didn't close their browser or clear their cookies). Session expiration will begin counting down based on the last action taken by a user. If the user takes some other action before 2 hours has passed their session should be "refreshed" and the count down will start again. This may explain the variance that some of the users are reporting from day to day as they may be active more one day than they are the other (e.g.: someone who is active over the course of a 12 hour period should stay logged in throughout that period, whereas someone who is active for 1 hour then inactive for 2 hours will have to log in again). 

 

If you're experiencing log-out issues which aren't explained by the above, please post back describing your experience and include a time stamp and your time zone so that Lithium can check their logs.

 

 

 

Thanks,
Liz

Did my post answer your question? Accept as Solution to help others find it faster.--------------------------------->