I'm pretty sure my bank website leaves me logged in longer than classicoldsmobile.com.

I joke.

But is there a setting to stay logged in longer? I use the facebook login if that matters? Most car forums I just hit refresh and I'm still logged in, many hours later.

Just curious, not a complaint. Thanks to those who keep the lights on here btw!

 

I have never ever been logged out here.

 

Do you login via your FB username/PW?

 

Same here. I do not associate with FB. Why use a surrogate for logging into CO? Just log in like “normal”.

 

It happens sometimes with my phone, but never with my PC.

 

i switched to user name and password login. let's see if that solves it.

i use fb to coordinate with locals for car related events. also, for some makes/models there are fb groups better than forums.

for my toronado, nothing beats classicoldsmobile.com

 

I just never log out. I close the page. When I open it back up I am always logged in. I have zero to do with fakebook.

Agreed. I just come to Classic Oldsmobile and there I am. I have never been logged out. Not once. Like I said I have zero to do with fakebook. I am using my phone (not an I phone) pretty much 99 percent of the time.

 

switching to name/pwd login solved the problem.

 

Interesting. I login with my Droid pretty much every time I browse the site. I'm logged off pretty quickly if I don't stay active (a few hours at most). I'm not sure if it's a setting I selected, or what?

 

Jesse - Do you login via FB?

 

No, I login via. the website. I rarely use FB.

 

Yes, it does matter. Anytime you use FB (or Google, etc.) credentials (username/PS) to login to any website (CO in this case) you are using a basic form of SSO (Single Sign On) authentication - similar to Pass Through Authentication. Essentially, the CO website leaves the authentication and security access token up to Facebook (i.e. CO trusts FB). In doing so, the CO website does not load a CA (Certificate of Authority) onto the device you're logging in with since CO trusts FB, authentication and issuance of a access token is controlled via FB not CO.

There are (many) caveats to SSO (Pass Through) authentication. There existed a time when CO did not integrate FB login. Every CO member required a unique member name & PW. With the implementation of FB login for the CO website, the policies for negotiating a FB login was accomplished by CO administrators & developers FAR up the food-chain. The very basics would have been to (1) accept default FB login policies/parameters; or (2) customized the FB login policies/parameters. In doing so, a CO Administrator &/or Developer established the Session Length and Signed-in Options. Both Session Length & Signed-In Options are left to the discretion of CO. The default normal FB Session Length & Signed-in Option is issuance of a Short-Lived access token (~1 hour) as opposed to a Long-Lived access token (60 days). Again, these policy parameters were selected &/or customized via CO when they installed the FB login API (Advanced Programming Interface). And, yes, a FB login is specific to the type of Browser the end-user utilizes & the h/w device which the end-user utilizes to negotiate the FB login.

 

Everyone logs in via the website (LOL) but I know what you're referring to. You login w/ a CO member name/PW. Without getting really ugly (down into the bowels of security authentication) there are a host of CO security policy parameters which can be employed/enabled by a CO Administrator/Developer for anyone. Moderators/Administrators are not provided (in general) the same login security policy parameters as a standard CO member (for obvious reasons). Obviously, I can't speak to those CO policy parameters & it would be far removed from the point of this discussion. In the end, however login policies are highly dependent on CO "role" (mod/admin/member, etc.), Browser & h/w device. There are quite often very select differences between session login policies/parameters based simply upon h/w (PC, mobile, laptop, etc.) & Browser. Sorta/Kinda like the delta between logging onto any website via Internet Explorer, Edge, Mozilla, Safari, Chrome, etc. The actual security policy access token "negotiation" takes place via the Browser which is obviously dependent on the h/w it is loaded onto.

 

The delta between a mobile (Wireless) device & a hard-wired PC device (even if the PC is WiFi enabled via a router) is issuance of the IP address (as you I'm sure know). Normally a hard-wired h/w device is issued a static (fixed) IP address (whether that device is a router, modem or PC) and a mobile device is issued a dynamic IP address. This is primarily because of the nature of a mobile device - it is a roaming mobile device which moves between various locations; albeit, it is often provided a new IP address throughout the day as the mobile device changes locations. This is not always the case but it is the general rule. With that said, even a mobile device which doesn't roam is often provided a different (dynamic) IP address throughout the day. Obviously, you can test this by simply turning off the mobile device and turning it back on (there are even simpler ways) - you'll be provided a different IP address. In the grand scheme of things, if the IP address has changed, the security access token is invalid & you'll be logged off any sessions previously employed with the invalid IP address because the bit value has changed losing the access token.

 

Last but not least, a word of caution (since it's free anyway). Websites want to make the sign-on/login process as seamless as possible for end-users which gave rise to the SSO (Single Sign On) &/or social sign on interface. However, usage of these sign-on authentication methods is replete w/ security compromises - the least of which is your every jump, move & hurdle is being tracked via that little SSO bit used to negotiate the sign-on/login. It is always to the benefit of any end-user to create a dedicated member/user name & PW for each site & never to allow a SSO authentication method such as Facebook, Google, etc. As an example:

Not exactly the same (as the above example), but in the background your identity is being tracked because that one little bit of information (your login credential authentication) is being tracked (by default) when you login using a SSO method. Today's kiddies (hackers, trackers, spammers, etc.) love this type of information because it's like candy. If they get into a website's ACL (Access Control List) they have keys to the kingdom. The ACL is where all security authentication takes place. If they get that list, say goodbye to most if not all of your login information for all your sites, credit cards, banks, etc., etc., etc.

 

Very interesting info! I just came back and find that I'm still logged in. Exactly how I want it to work. Lesson learned regarding SSO. I figured it'd be convenient, and it turned out to be the opposite of convenient

 

Most likely inconsequential to most members is the "status" symbol (icon)...located beneath a CO member's name on various threads. Every website handles this status icon differently, some websites don't display any form of status symbol. You may, on various occasions notice the status symbol is green or the status symbol is gray (blanked out, not green). CO policy parameters for this symbol are defined by Administrators/Developers further up the food chain. The symbol contains a TTL (Time To Live) parameter/function.

Example: If you leave your device on with a connection to CO but you have not been active for an extended period of time, the status symbol will change - this is normal behavior. It reflects a CO members status. Green = Active, Grayed Out = Inactive (even though the member is logged in). As soon as you become Active, the symbol will change from Grayed Out>Green. The default TTL is (again) controlled by CO Administrators/Developers further up the food change. Example (again): You have a connection to CO, you go to bed, you open your Browser to CO and your status displays Grayed Out (not Green). As soon as you become Active, the symbol will change to Green.

 

Forgot to provide an image for visual reference...

 

+1