cbe_frontauth: Connect to (and disconnect from) backend from frontend

CeBe · 2011-07-27 09:00:31

This plugin answers an old question asked in the french forum: se connecter depuis une page du site.

It provides the ability for a registered user to connect to Textpattern’s backend from a frontend page.
Can be extended with cbe_members to add the ability for an author to change and reset his password from frontend.

Its main functions are :

display a login form to connect
display a logout form or a link to disconnect
combine these two functions into a box which automatically shows the right form (or link)
automatic redirection after successful login and/or logout
protect parts of a page

Read the help to learn more, and download from GitHub:

as plain text
or in a zip file

Feel free to post your comments/questions right below, place is yours :)

— Changelog:

20 Nov 15 – v0.9.7 – Fix this
07 Apr 14 – v0.9.6 – Error when processing presentational attributes in cbe_frontauth_edit_article
04 Apr 14 – v0.9.5 – Missing last access storage
27 Mar 13 – v0.9.4 – Basic message if login fails – Customisable strings (by editing the first lines of the plugin) – Fixed: missing initialisation for cbe_frontauth_whois
22 Aug 12 – v0.9.3 – Doc typo for cbe_frontauth_invite
?? ??? 12 – v0.9.2 – ??
22 Mar 12 – v0.9.1 – Fixed missing attributes (show_login and show_change) for <txp:cbe_frontauth_box />
21 Mar 12 – v0.9 – Users can now change or reset their password from frontend. See cbe_members
10 Jan 12 – v0.8 – New tag <txp:cbe_frontauth_loginwith /> and new functionality: email address can be used to log in, here is where the idea comes from
05 Jan 12 – v0.7.1- Documentation addenda
06 Aug 11 – v0.7-beta
- Introduces <txp:cbe_frontauth_edit_article />
- CSRF protection ready
- Documentation improvements (easier to read)
29 Jul 11 – v0.6-beta
- Optimizations to avoid multiple calls to database when retrieving user’s informations
- Added name and privilege controls à la <txp:rvm_if_privileged />
- Minor changes to documentation
27 Jul 11 – v0.5-beta- First public beta release

Last edited by CeBe (2015-11-20 20:40:54)

Bloke · 2011-07-27 09:10:16

Ahhh, the merger of rvm_privileged and ign_password_protect in a neat package. Bliss!

Thank you Claire, this is going in my must-have list for client access. I might even give it a whirl on the new textpattern.org site, because I’ve currently had to code the login/logout portion manually by integrating rvm_privileged and custom code. This might save me a truckload of effort so I’ll try it out when I get a chance. Superb stuff.

CeBe · 2011-07-27 09:32:46

Great news, Bloke :)
And thank you !

Pat64 · 2011-07-27 09:35:00

@Stef

Yeah. This girl is amazing! WordPress had it. It’s turn now for TXP.

Thanks Claire for the time spend on this very helpful plugin.

Zanza · 2011-07-27 09:38:09

Thank you for this plugin, often needed something like this!

Just to be sure (before trying): this doesn’t cover the self-register part? Should we still use mem_self_register for that, isn’t it?

If true, do you plan to integrate also a self_register function in the future? For hidden content, showing a login box is not enough if there is not an automatic way to self register.

Also, there is a way to serve different content based on author level? If not, I suppose that inside your tags we could always use rvm_privileged.

CeBe · 2011-07-27 10:50:36

Zanza a écrit:

Just to be sure (before trying): this doesn’t cover the self-register part?

No, it doesn’t and most likely never will as registration is already holded by the backend and mem_self_register.
I just stucked to the demand which was : I want to be able from the fontend to connect to my backend account, and if I am connected to see something special for me.

For hidden content, showing a login box is not enough if there is not an automatic way to self register.

I am not sure to understand why it’s a problem (frankly, I’m not sure to understand the scope of the question).

If it helps, you can have in one page a (or several) login box(es) AND protected content(s).
In the following examples, note that <txp:cbe_frontauth_protect /> and <txp:cbe_frontauth_if_logged /> (or <txp:cbe_frontauth_if_connected />) are synonyms.

All-in-one:

<txp:cbe_frontauth_protect>
  ... Private content here ...
<txp:else />
  <txp:cbe_frontauth_box />
</txp:cbe_frontauth_protect>

Or, still all-in-one:

<txp:cbe_frontauth_protect>
  <txp:cbe_frontauth_logout />
  ... Private content here ...
<txp:else />
  <txp:cbe_frontauth_login />
</txp:cbe_frontauth_protect>

At different places:

<!-- main content !-->
<txp:cbe_frontauth_if_logged>
  ... Private content here ...
</txp:cbe_frontauth_if_logged>

<!-- sidebar !-->
<txp:cbe_frontauth_box />

Also, there is a way to serve different content based on author level? If not, I suppose that inside your tags we could always use rvm_privileged.

I haven’t tried, just had not the idea to. But I am planning to add this feature in a future release.
Until then, why not trying rvm_privileged.

Last edited by CeBe (2011-07-27 10:55:09)

Bloke · 2011-07-27 11:05:07

CeBe wrote:

I’m not sure to understand the scope of the question

I think Zanza (correct me if I’m wrong) is saying that traditionally, when you click a link to obtain access to some protected content and you are faced with a login box, there is almost always a ‘register’ link nearby so somebody who does not yet have an account can sign up for one. I think the question is therefore: “will cbe_frontauth be getting self-registration capabilities?”

As it stands, with your plugin we can do this:

<txp:cbe_frontauth_if_logged>
   // Private content
<txp:else />
   <txp:cbe_frontauth_box /> or <a href="/register">Register</a>
   // Benefits of registering listed here
</txp:cbe_frontauth_if_logged>

And the /register link would run mem_self_reg code to allow signup.

Last edited by Bloke (2011-07-27 11:05:38)

CeBe · 2011-07-27 12:00:50

Bloke a écrit:

traditionally, when you click a link to obtain access to some protected content and you are faced with a login box, there is almost always a ‘register’ link nearby so somebody who does not yet have an account can sign up for one.

Ok, I got the idea.

I think the question is therefore: “will cbe_frontauth be getting self-registration capabilities?”

cbe_frontauth focuses on allowing access to backend for a user who has already an account there, as primarily asked by Niconemo.

My point of view is that going further will take us slowly but surely to a more advanced user management. I agree this a logical continuation, but I don’t feel that it should be done by cbe_frontauth. I would even say that I don’t have to re-invent the wheel (unless cbe_frontauth and mem_self_register don’t play together well):

registering as a backend user is already handled by the backend and mem_self_register
registering as a frontend user is implemented in ign_password_protect when using a custom database

As it stands, with your plugin we can do this:

To be fully complete, you can cutomize cbe_frontauth_box like this:

<txp:cbe_frontauth_if_logged>
   // Private content
<txp:else />
   <txp:cbe_frontauth_box>
      <txp:cbe_frontauth_logname />
      <txp:cbe_frontauth_password />
      <txp:cbe_frontauth_submit /> <txp:cbe_frontauth_link link= "/register" linklabel="Register" />
      <p>What you get as a registered user: ... </p>
   </txp:cbe_frontauth_box>
</txp:cbe_frontauth_if_logged>

Or use <txp:cbe_frontauth_box form="login_register" /> and put all the enclosed tags in login_register.

Last edited by CeBe (2011-07-27 13:24:57)

Bloke · 2011-07-27 12:17:45

CeBe wrote:

going further will take us slowly but surely to a more advanced user management.

Agreed. The future’s much rosier with your plugin around. smd_user_manager and the new smd_bio should be out later today, btw, which will hopefully give people one more excuse to consider Textpattern when dealing with community or large userbase sites.

I don’t feel that it should be done by cbe_frontauth.

Fair enough. mem_self_register works, though it’s tightly integrated with ign_password_protect (in terms of the fact they can both use the same separate user table). I don’t particularly like the separate table, as I prefer to keep all my users in one place and then extend their profiles with smd_bio [I’m intending to enhance smd_bio again in the near future to allow you to easily build input forms on the public side for capturing extended bio data at registration time, so that’ll require integration with mem_self_reg / mem_form].

One plugin to rule them all is great, but I don’t mind using a few to get the job done if they play well together. More flexibility that way imo.

Last edited by Bloke (2011-07-27 12:18:22)

michaelkpate · 2011-07-27 13:00:31

I tried to do a site years ago that had this sort of thing and never could get it to work. I think this opens up some very exciting capabilities and I can’t wait for a chance to really try it out.

Zanza · 2011-07-27 13:23:11

Bloke wrote:

I think Zanza (correct me if I’m wrong) is saying that traditionally, when you click a link to obtain access to some protected content and you are faced with a login box, there is almost always a ‘register’ link nearby so somebody who does not yet have an account can sign up for one.

Exactly, Bloke, thanks.

As it stands, with your plugin we can do this:

(code snippet..)

And the /register link would run mem_self_reg code to allow signup.

Yes. That only means that you have to go to another page to sign up (it’s ok, just wanted to be sure) and that you have to use two plugins (three with rvm_privileged, four or five with smd_ combo) to have a decent user management with restricted content. It’s good enough, I was able to use mem_self_register and ign_password_protect some times ago. I’m not sure if it would be better to have a unique plugin rather than a suite, but I have to play around it.

Thank you all for these alternatives.

CeBe · 2011-07-27 14:30:01

Zanza a écrit:

If not, I suppose that inside your tags we could always use rvm_privileged.

It appears that rvm_privileged, with <txp:rvm_if_privileged name="..." level="..."> just replaces the simplest form of <txp:cbe_frontauth_protect> (or …if_connected, or …if_logged).

I see only one reason to implement level control in cbe_frontauth: if you want to automatically display a link for some levels (<txp:cbe_frontauth_protect link="/special-url" linklabel="Your special link" />). It’s rather limited.

What do YOU, people, think about it ? Is it really worth it ? Does someone need it ?
Any other idea ?
Your opinion matters :)

Last edited by CeBe (2011-07-27 14:30:38)

Textpattern CMS

Textpattern CMS support forum

#1 2011-07-27 09:00:31

cbe_frontauth: Connect to (and disconnect from) backend from frontend

#2 2011-07-27 09:10:16

Re: cbe_frontauth: Connect to (and disconnect from) backend from frontend

#3 2011-07-27 09:32:46

Re: cbe_frontauth: Connect to (and disconnect from) backend from frontend

#4 2011-07-27 09:35:00

Re: cbe_frontauth: Connect to (and disconnect from) backend from frontend

#5 2011-07-27 09:38:09

Re: cbe_frontauth: Connect to (and disconnect from) backend from frontend

#6 2011-07-27 10:50:36

Re: cbe_frontauth: Connect to (and disconnect from) backend from frontend

#7 2011-07-27 11:05:07

Re: cbe_frontauth: Connect to (and disconnect from) backend from frontend

#8 2011-07-27 12:00:50

Re: cbe_frontauth: Connect to (and disconnect from) backend from frontend

#9 2011-07-27 12:17:45

Re: cbe_frontauth: Connect to (and disconnect from) backend from frontend

#10 2011-07-27 13:00:31

Re: cbe_frontauth: Connect to (and disconnect from) backend from frontend

#11 2011-07-27 13:23:11

Re: cbe_frontauth: Connect to (and disconnect from) backend from frontend

#12 2011-07-27 14:30:01

Re: cbe_frontauth: Connect to (and disconnect from) backend from frontend

Board footer