client side register/login form

colak · 2012-07-30 06:13:21

Is there a way to create a register and (after approval by a moderator) a login form which do not give access to the admin interface but give access to a particular section of the front end?

> Edited to add: would smd_access_keys hold the answer to this?

Last edited by colak (2012-07-30 07:23:02)

zero · 2012-07-30 13:42:27

Hi Yiannis, I do this by using a contact form plus this zubrag password protect script. It is simple to use and uses cookie for that day so user can browse inside and outside protected section. User has to login again next day.

I tried smd_access_keys but I can’t exactly remember why I didn’t use it. I think it was a bit too complicated for my needs and I would have had to protect the section page by page. I probably could have found a way round this but decided on the zubrag simplicity.

Dragondz · 2012-07-30 15:08:39

Hi Yiannis

mem_self_register and ign_password_protect are perfect for your case, you have only to use the alternate DB for ign_ to have people register in a table that are not related to textpattern admin.

Bloke · 2012-07-30 15:29:40

I would personally go with cbe_frontauth as it’s a more recent plugin, and more flexible than ign_pw_protect. It does use the Textpattern user table but there’s no intrinsic harm in doing so, provided you create a new user group for your non-admin-side users, or use priv level 0, which forbids admin-side access

You can either use bot_privs or smd_user_manager for creating new groups. And, in fact, if you go with the latter it has a <txp:smd_um_has_privs /> tag for helping you determine which privs a user has on the front-end so you can create more than one level of user (though contact me if you do this, because I have a new version available with a few minor fixes that I simply haven’t had time to release).

smd_access_keys really has a special use for unlocking digital downloads or protecting certain content with loooong keys. While it can be used in this case, a simple password system is good enough to allow access to an area or areas. If a section shares a page template then of course you only need to use the one smd_access_protect tag to protect them all.

It depends on what exactly you’re trying to protect and what’s least hassle for the end user.

Last edited by Bloke (2012-07-30 15:31:28)

colak · 2012-07-30 17:17:32

zero wrote:

I would have had to protect the section page by page.

This would not be a problem… read below

Dragondz wrote:

mem_self_register and ign_password_protect are perfect for your case, you have only to use the alternate DB for ign_ to have people register in a table that are not related to textpattern admin.

ing_might be the solution but….

Bloke wrote:

It depends on what exactly you’re trying to protect and what’s least hassle for the end user.

We are currently developing a site which might be harvested by europeana and we estimate to have about 150 ‘members’. The site will mainly be open for all but we also want a private section where we will have 4 quite involved zcr forms.

two for artists
- One to list an individual artwork
- one for bio and cv
one for galleries
one for publishers

I wish there was a way to have jpg attachments in the forms but this is another story:)

We do not want these forms to be accessible to the public but they will basically have fields which they will provide us with particular information to add to the site. A kind of moderation I guess.

The reason we want the register/approve/login/post/copy-paste system is because we do not want any guests (or other artists/galleries/publishers) to provide us with any false info (don’t ask!).

Hackers aside, what we hope is to find a way where the password protected forms will also have a “key” send to us which will confirm that the user is the one with the given password…

too complex? Possibly!

colak · 2012-07-31 06:33:56

I’m looking at cbe_frontauth which looks very appropriate.

Textpattern CMS

Textpattern CMS support forum

#1 2012-07-30 06:13:21

client side register/login form

#2 2012-07-30 13:42:27

Re: client side register/login form

#3 2012-07-30 15:08:39

Re: client side register/login form

#4 2012-07-30 15:29:40

Re: client side register/login form

#5 2012-07-30 17:17:32

Re: client side register/login form

#6 2012-07-31 06:33:56

Re: client side register/login form

Board footer