Good way to piggyback a modal on session timeout?

[rcane]

I have need for a modal to get a yes/no click from users —at least once a login. 

So, if they timeout and need to login again I want to have the modal pop up.

It'll push their answer to a table for record keeping but that's easy.

I'm trying to figure out how to track the session or just find the end of the login before index template takeover—-for lack of a better word.

[Arantor]

What does "once a login" actually mean?

The things you talk about are not how reality implements any of it.

Because in my world if I select "login forever" during login, I login precisely once and my session recreates after 20 minutes of idle on the site (default SMF parameters) so using both login and session are worthless for anything meaningful.

What are you actually trying to achieve here?

[rcane]

"once a login" meant once during the session where they are logged in---right after they have logged in to be more precise.  If they log out using 'log out' then they'd qualify to do "it" again.

//"it" being a modal that requires a yes/no answer.

If someone did have "stay logged in forever" then there would need to be a timer of sorts that, off the top of my head, would be something like once every 24 hours or so (just throwing a number out there since folks usually come in for a few minutes, get some data and then scoot). 

I'm not familiar with the actual terms of the processes SMF uses in the realm of logging in and keeping an eye on your session so I'm trying to not lead you one way or the other except to say:   

logging in, you get to see a modal. 
if you're logged in forever, you'd need to see that modal once in a while [a day perhaps]

[Doug Heffernan]

This will require a custom mod imo to be done properly.

[Arantor]

"once a login" meant once during the session where they are logged in---right after they have logged in to be more precise.  If they log out using 'log out' then they'd qualify to do "it" again.

//"it" being a modal that requires a yes/no answer.

If someone did have "stay logged in forever" then there would need to be a timer of sorts that, off the top of my head, would be something like once every 24 hours or so (just throwing a number out there since folks usually come in for a few minutes, get some data and then scoot). 

I'm not familiar with the actual terms of the processes SMF uses in the realm of logging in and keeping an eye on your session so I'm trying to not lead you one way or the other except to say:   

logging in, you get to see a modal. 
if you're logged in forever, you'd need to see that modal once in a while [a day perhaps]

So as suspected it is in fact literally nothing to do with "when the user logs in" and literally nothing to do with sessions, because as I said, these things literally do not work in reality the way you imagine them to work.

You will need to do this with custom code, but the correct way to do this is precisely nothing to do with sessions or logins.

1. Create a new column in the members table of type int(10) default 0.
2. This value will be available in $user_settings (you can put it into $user_info if you wish, inside the load-user routine in Load.php but honestly this is an afterthought)
3. During *logout* reset this value to 0.
4. On a regular page load, check if this value is zero or that if compared to time() it is more than 86400 seconds apart.
5. If it is, show the modal. Assuming you're just annoying users with a warning message, you can just show the modal and immediately update the aforementioned column with the value of time() to reflect the last time they saw it.
5a. If you're trying to get the user to reconfirm they've seen it, you will need to do more work to not update that value until the user does something specific and use *that* to update the modal.

I have no idea what you're possibly doing that needs the user to reconfirm that frequently but that's how you'd meaningfully do it.

[rcane]

thanks everyone.  I'll go do some reading to see if I want to continue. 

[rcane]

"once a login" meant once during the session where they are logged in---right after they have logged in to be more precise.  If they log out using 'log out' then they'd qualify to do "it" again.

//"it" being a modal that requires a yes/no answer.

If someone did have "stay logged in forever" then there would need to be a timer of sorts that, off the top of my head, would be something like once every 24 hours or so (just throwing a number out there since folks usually come in for a few minutes, get some data and then scoot). 

I'm not familiar with the actual terms of the processes SMF uses in the realm of logging in and keeping an eye on your session so I'm trying to not lead you one way or the other except to say:   

logging in, you get to see a modal. 
if you're logged in forever, you'd need to see that modal once in a while [a day perhaps]

So as suspected it is in fact literally nothing to do with "when the user logs in" and literally nothing to do with sessions, because as I said, these things literally do not work in reality the way you imagine them to work.

You will need to do this with custom code, but the correct way to do this is precisely nothing to do with sessions or logins.

1. Create a new column in the members table of type int(10) default 0.
2. This value will be available in $user_settings (you can put it into $user_info if you wish, inside the load-user routine in Load.php but honestly this is an afterthought)
3. During *logout* reset this value to 0.
4. On a regular page load, check if this value is zero or that if compared to time() it is more than 86400 seconds apart.
5. If it is, show the modal. Assuming you're just annoying users with a warning message, you can just show the modal and immediately update the aforementioned column with the value of time() to reflect the last time they saw it.
5a. If you're trying to get the user to reconfirm they've seen it, you will need to do more work to not update that value until the user does something specific and use *that* to update the modal.

I have no idea what you're possibly doing that needs the user to reconfirm that frequently but that's how you'd meaningfully do it.

I sketched out something like that using a dedicated table versus _members.

Q:  any column added to members needs to be declared in load.php?  Meaning, just adding column "banana" doesn't automatically create $user_settings['banana'] to be used at will...

Q:  this would have to be done to get into _settings as well as _info, no?


Q:  is there a benefit to using one or the other?


Q:  is it only defined in load.php?  I was skimming it and didn't see where they would take place.


Thanks for the patience.