Logout using <txp:password_protect />

gfdesign · 2012-11-28 17:26:58

Hi everyone
I wonder if it’s possible to create a Log out link when you are watching contents protected by <txp:password_protect /> tag.
I think it should be useful especially when you’re in a public computer (such as cybercafe, school, etc)
I know about ign_password_protect plugins, but I’ll have many protected articles for differents users (one article per user), so I would use <txp:password_protect /> rather than ign_password_protect so, this way, I could put the user & password in the same article using custom_fields.
Any idea?
Thanks in advanced

whaleen · 2012-12-10 10:23:12

Install cbe_frotnauth

Make a logout link:

<a href="?logout=1">Log out</a>

helsinkifrostbites · 2022-07-20 12:54:48

I realize this thread is a decade old, but I have the same problem as the gfdesign, and the logout link doesn’t work. Is there a currently working solution?

etc · 2022-07-21 10:55:50

There seem to be no easy way to unset clients Authorization header used by <txp:password_protect />, but you can replace it by another one on logout. Replace where appropriate

<txp:password_protect login="user" pass="password" />

with

<txp:password_protect login="user" pass='password<txp:page_url type="logout" />' />

and access this page via a HTML form sending, say, logout=password input. Txp will prompt you to login. Using user and passwordpassword should actually log you out.

This may certainly be naive security-wise, so test if one can easily circumvent it.

helsinkifrostbites · 2022-07-28 12:05:44

Thanks, etc! I’ll look into this. :)

jakob · 2025-01-10 15:54:01

I’ve been asked to provide a “logout” link for a section protected using txp:password_protect to ensure another user on a jointly used computer can’t use a still-open session.

Presumably, I just direct the “logout”-link to another “logout” page with the tag above. If the correct person wants to revisit the “internal” area, will they be reshown the password entry dialog box when they visit the internal area again?

Also, is there a way to detect if a login session is currently active? I’d like to add some site-wide navigation items (i.e. not just in the specific protected section) that are only visible when the credentials have been already been supplied.

etc · 2025-01-10 23:55:18

jakob wrote #338737:

Presumably, I just direct the “logout”-link to another “logout” page with the tag above. If the correct person wants to revisit the “internal” area, will they be reshown the password entry dialog box when they visit the internal area again?

Presumably yes, though I have not tested it extensively. But it does not have to be another page. To logout, the user will need to either submit password{logout} password, where {logout} is the URL logout param value, or (better) click Cancel button.

Also, is there a way to detect if a login session is currently active? I’d like to add some site-wide navigation items (i.e. not just in the specific protected section) that are only visible when the credentials have been already been supplied.

Yes, you can check $_SERVER['PHP_AUTH_USER'] and $_SERVER['PHP_AUTH_PW'] values, possibly via <txp:if_request /> tag. Note that, since these values are session-wide, you can not simultaneously access two or more pages protected with different credentials (which makes this ‘logout’ hack possible).

jakob · 2025-03-19 22:18:53

Sorry to defrost an old thread, but I’ve been trying this out, and the password_protect is not really cutting it after all …

I can access the SERVER variables fine with <txp:if_request> and it works on the section that is protected but when I switch to another (non-protected) section, if_request does not return the server / user authentication variables. I read that I need to transfer the authenticated user to a session variable, such as $_SESSION['user'] in order to then access that session variable – after initiating <txp:php>session_start();</txp:php> – on another section of the site. That does work, however logging out is a bit hit and miss. It sometimes succeeds, sometimes not (especially when the logout page is not on the protected section). Also, the users get presented with a login form when logging out, which is counter-intuitive…

Long story short, I’ve tried switching over to mck_login (after registering the public tags), and the UI handling is altogether more pleasing. I can show a login form within the page UI and only reveal the content once logged in. On the other pages, the regular <txp:if_logged_in> tag can be used to add a logout link etc. The logout link also returns the user cleanly to the home page, etc.

But one question still remains: I’ve created a single user with privileges of 0 for this, however this login will be used by multiple people on different computers and locations. Are they going to be stealing the login credentials from one another if they login in parallel? Can I get around this, i.e. can a user be logged in from multiple locations/devices? If not, what other options do I have?

Bloke · 2025-03-19 23:32:14

jakob wrote #339334:

password_protect is not really cutting it

It’s a really bad implementation of a bad HTTP protocol. But there’s very little we can do because that’s how the stupid spec works.

I way prefer the interface and workflow of mck_login.

I’ve created a single user with privileges of 0 for this, however this login will be used by multiple people on different computers and locations. Are they going to be stealing the login credentials from one another if they login in parallel?

They will clobber each other. When someone else logs in, anyone who is currently using it will be kicked off.

Can I get around this, i.e. can a user be logged in from multiple locations/devices?

Not at present. Ruud (I think, or it might have been Robert) set up the expiring logins way back in 4.6.0, maybe before. The only way I can think of bypassing it is to hack core back to its previous state. Maybe we should offer a preference to govern whether shared logins are permissible or not? There are times during development where it’s a royal pain to have to create two accounts so I can test things on multiple browsers or on regular + incognito sessions.

jakob · 2025-03-20 07:42:29

Thanks for the candid feedback. I thought as much. I guess that means all 20 sub-groups, many of which have a small team, will need their own logins.

Bloke · 2025-03-20 10:45:41

Depending on if you’re comfy running 4.9.0 on the site in question, let me look into the feasibility of offering a pref. Might not work, but I’ll let you know later today or first thing tomorrow.

jakob · 2025-03-20 11:10:10

Yes, latest 4.9 beta 2 is in service. I’ve currently set it up with just the one shared user. If it should be a simple task, I’d love to hear back on that (my meeting is tomorrow morning too) before I create multiple logins. No problem if that’s pushing it, of course.

Aside: I incorporated gas-kirito’s latest modifications to mck_login, added public tag registration, fixed an error I was seeing on logout, and generally refactored the plugin to correspond to the new plugin folder organisation. I put that up on GitHub as a minor mck_login v0.1.2 release. I’ll add a note to your post further up and the relevant thread.

I’ve not tested the whole range of functionality just yet, so should you have additions / improvements of your own, I’ll gladly incorporate them.

Textpattern CMS

Textpattern CMS support forum

#1 2012-11-28 17:26:58