ign_password_protect

kevinpotts · 2011-06-29 20:58:30

Let me know if this solves the issue.

Yes, indeed it did. I completely deleted the old one and installed this fresh, and everything is in order. Working on a 4.4.1 install, this seems to be completely operational. Thanks everyone for their speedy work on getting this issue patched — it is truly appreciated.

Update: The only thing I see, and it’s a minor issue, is that the Help for the plugin is being displayed unformatted. No big deal, but thought I would report back.

Last edited by kevinpotts (2011-06-29 21:01:00)

igner · 2011-06-30 04:26:52

And in a rare fit of compulsion, I tracked down the issues with the alternate db – changes have been committed to github, a compiled plugin is here

Note that this release does break support for wildcarding the domain when logging in on the public side – so the logged-in session will be specific to the domain in use when the user logs in (e.g. if a user logs in from www.domain.com, but gets redirected to domain.com, the session will be invalidated). I am still looking at that particular issue, just no guarantees of when it’ll be addressed.

Edit: scratch that caveat – tracked down that problem, cross-sub-domain wildcard support should be working again. If it’s not, let me know.

Last edited by igner (2011-06-30 04:51:01)

Dragondz · 2011-06-30 08:57:54

Thanks igner

you are a chief :)

Tested and it seems to work like expected

brunodario · 2011-07-08 22:07:21

How can i set the plugin to not keep a user logged in if the browser is closed and then re-opened, i know i have to change the cookie definition to “0” but i wasn´t able to find the correct line, can someone please point this?

And a little bit more far, is there a way to set a certain time of inactivity on site and then log the user off if he clicks a link / perform an action (just like phpmyadmin does, I.E)?

planeth · 2011-08-11 12:41:28

From a VERY cursory review of 4.4, that little bit of funkiness has been removed from TXP, hence the > 0 check in Manfre’s code above. The upshot is that it will likely be necessary to re-map user privileges somewhat, to use the common txp user database and limit users to front-end access. perhaps stef or one of the other core developers can enlighten a little bit.

I used a kind of ugly hack and add another element to $txp_groups array in textpattern/lib/admin_config.php.
For the need of my client it solved the problem of giving no privilege to a self registered user and still beeing able to log in with ign_password_protect.
I understood that in the next version of textpattern the permission setting will be move to the DB. Then would it mean that we could add new user privilege ?

aslsw66 · 2011-09-25 20:41:38

I’m trying to implement a test for the first time a new user logs in – you know the sort of message you often get eg. welcome, how to change passwords etc. I assume there is nothing within the current ign_password_protect functionality to help me out, because it immediately writes to the last_access field in the ign_users table on the first login.

I’m trying a few scenarios (mainly with an additional field), but I think this would be really useful functionality to build into the core of the plugin.

Dragondz · 2011-09-26 10:46:21

Hi Anura

There is such a feature on mem_self_register plugin (reset password, change password, …).

Cheers

Bloke · 2011-09-26 11:06:42

aslsw66 wrote:

I assume there is nothing within the current ign_password_protect functionality to help me out, because it immediately writes to the last_access field in the ign_users table on the first login.

Hmm, yeah a tricky one. Both Txp’s login mechanism and ign_pw_protect set the last_access immediately so I think the only way to do this would be to hack the plugin. Since 4.4.0 you can separate the login process by doing a query-only credentials check without setting the last_access. So this is the process igner would probably use:

check login is valid without updating last_access (call txp_validate() with third arg set false)
assuming (1) passes, test last_access field: set a flag depending on content
call txp_validate() again (with third arg=true or omitted) to set the last_access and log the person in

Once the ign_if_logged_in (or other tag) has been retrofitted with the ability to test the status of the flag set in step 2, it’s game on (at least, I think that’d work).

Last edited by Bloke (2011-09-26 11:11:12)

aslsw66 · 2011-09-26 14:09:28

The other option I was thinking was to add a new field to the ign_users table for the first login. If it’s the first login, I could display the welcome message and then update it using smd_query. It doesn’t sound ideal because of (1) overhead from additional database queries and (2) it’s another field to add to the table.

I’ll try to play with both options, but frankly the database route is easier for me (but not everything worth doing in life is necessarily easy!).

Bloke · 2011-09-26 14:28:27

aslsw66 wrote:

The other option I was thinking was to add a new field to the ign_users table for the first login

If you’re going that route it might be easier to approach it differently with a few lines of php. Something like this (untested):

<txp:php>
   global $variable, $txp_user;
   $users = do_list(get_pref('aslsw66_users', ''));
   if ($txp_user && !in_array($txp_user, $users)) {
      // Person's first login
      $variable['first_login'] = '1';
      $users[] = $txp_user; // Add user to array
      set_pref('aslws66_users', join(', ', $users), 'aslsw66', PREF_HIDDEN, 'text_input', 0); // Store latest user list
   }
</txp:php>

That uses the txp_prefs table to keep a list of people who have logged in instead of faffing about with the users table. From that point on — you can include that code on every page via good ol’ output_form — you can use txp:if_variable to check if it’s first login time.

Last edited by Bloke (2011-09-26 14:32:19)

aslsw66 · 2011-09-28 21:18:48

That would still be another database query wouldn’t it? Also, part of me thinks it would be neater to keep all of the data about a user together with their record in the table (don’t talk to me about faffing about with the users table, I’ve already done it and am trying to figure out how to reverse engineer smd_bio to correct that mistake!).

Bloke · 2011-09-28 21:40:42

aslsw66 wrote:

That would still be another database query wouldn’t it?

get_pref() doesn’t incur any penalty by default but, yes, set_pref() will add one query when a user logs in for the first time.

Also, part of me thinks it would be neater to keep all of the data about a user together with their record in the table

As you wish.

reverse engineer smd_bio

Good luck with that: I struggled to forward-engineer it ;-)

Of course, you could just add a bio field called first-login or something and ask people not to change it from the admin side (assuming you have smd_user_manager installed). If you don’t use smd_um then you can set that bio field up and just gloss over it when displaying your bio data. Use smd_query to set it to 1 after you’ve tested its value. Note to self: maybe hidden fields might be a useful addition.

Textpattern CMS

Textpattern CMS support forum

#805 2011-06-29 20:58:30

Re: ign_password_protect

#806 2011-06-30 04:26:52

Re: ign_password_protect

#807 2011-06-30 08:57:54

Re: ign_password_protect

#808 2011-07-08 22:07:21

Re: ign_password_protect

#809 2011-08-11 12:41:28

Re: ign_password_protect

#810 2011-09-25 20:41:38

Re: ign_password_protect

#811 2011-09-26 10:46:21

Re: ign_password_protect

#812 2011-09-26 11:06:42

Re: ign_password_protect

#813 2011-09-26 14:09:28

Re: ign_password_protect

#814 2011-09-26 14:28:27

Re: ign_password_protect

#815 2011-09-28 21:18:48

Re: ign_password_protect

#816 2011-09-28 21:40:42

Re: ign_password_protect

Board footer