ign_password_protect

photonomad · 2005-12-31 16:33:08

Can’t seem to get login_msg to work with the ign_password_protect tag:

<txp:ign_password_protect login_msg=“please login below” err_msg=“oops! check your username and password and try again.” remember=“1”>

instead of saying: please login below, it still says the default: Access to this area restricted to registered users, please log in.

err_msg works fine.

——————————————————————————————————————————————————————————-

I figured out the problem I was having earlier:

I was was having trouble with being re-directed to the home page regardless of whether my login was correct or incorrect — the problem was that I was using messy URLS…. I installed the plugin on a different site that uses clean urls and all was well.

——————————————————————————————————————————————————————————-

Last edited by photonomad (2006-01-05 03:34:48)

bauhouse · 2006-01-16 19:35:28

Client login area

I was wondering about the possibility of having a conditional tag to allow an individual user to access content specific to that user, similar to what was asked by lee in a previous post in this thread regarding the possibility of setting up a client login area. Perhaps this might work with the existing ign_if_logged_in tag with another attribute: “username”. That way, if all the clients had the same privilege levels but you wanted to restrict the available content to a specific client, you could use the following code:

Or as an alternative, one could set the privileges for a page with something like this:

igner, would this be difficult to achieve?

igner · 2006-01-16 20:01:21

bauhouse – hmmm, one method I can think of that would net you a quick and dirty solution would be to use a unique privilege level for each client – requires editing the privelege levels at the top of the plugin, and if you have common sections / pages that need to be accessible to some, but not all, clients (and secured from non-clients), you’d have to tweak the privs on each of those pages as well. Let me know if this makes sense.

bauhouse · 2006-01-16 20:09:28

Thanks, igner. I thought I had made a fairly thorough reading of the previous posts to make sure this hadn’t already been covered. I now see that soulship already asked this and you gave an example of how this might work. I’ll give this a try.

Btw, great plugin!

noods · 2006-01-20 04:49:36

I dunno if im doing anything wrong here, but with the txp:ign_self_edit tag, im assuming you just insert it as it as?

When i do, the form to change the password comes up as expected, but it doesnt actually do anything – it doesnt verify if you have put in mismatching passwords – it just spits you back to the index.php.

Also, it doesnt sent out an email, nor does it actually change the password

if anyone could help us out here, that would be greatly appreciated

-noods

Last edited by noods (2006-01-20 04:50:18)

igner · 2006-01-20 16:02:51

noods – that function should probably be labeled as “experimental”, or maybe “half-assed”. I didn’t put much planning into that piece, primarily because there is significant overlap with mem_self_register, and in fact seriously considered removing it entirely. All that’s a long-winded way of saying that that’s functionailty that I haven’t tested since I originally added it, and it’s distinctly possible I broke it the last time I touched the code. I’ll see if I can’t take a look this weekend.

Sorry for the inconvenience…

dominik.osterholt · 2006-01-20 18:52:48

Hi igner,

I’ve modified your great plugin a little bit for my own purposes, e. g. I’ve managed to have a graphical login mask in my navigation which can be seen permanently. There’s one section to be protected by your script (which happens in the page). It’s working fine so far, but now I’m stuck with the following:

Is it possible that the cookie your script writes is being ignored as soon as I’m using a permlink? I have a navigation (and subnav) that bases on sections, and as long as I use txp:section tags in my forms, everything’s fine: the user stays logged in (I can see that by a “logged in” message that is then shown below my nav). But as soon as I’m linking a certain article directly by it’s permlink, the user seems to be logged out automatically and also has no access to the protected section anymore.

Any ideas why?

add.: Guess I solved it. I was partly working with links beginning with “http:…”. Using relative links such as “/section/article” works fine. But as far as I know, permlinks have a “http:…” at the beginning, right? So if I had to use those, was there a solution for me?

Last edited by dominik.osterholt (2006-01-20 19:05:56)

igner · 2006-01-20 19:33:52

Dominik -

First guess based on your addendum is that is that the host in the permalink doesn’t match the host in the cookie – http://example.com/ and http://www.example.com/ may resolve to the same host, but are not the same host as far as a cookie is concerned. Beyond that it’d be easier to sort out if I could see it.

igner · 2006-01-22 23:05:35

dominik – the problem you’re running into is that you’re using two different host names for the site: example.com and www.example.com may resolve to the same host, and your site may be served up in either case, but as far as cookies and your browser are concerned, these are different hosts. A cookie set for example.com my not be read from www.example.com, so in your case I’m betting that you’re accessing http://example.com but have the site URL set up in TXP as http://www.example.com.

Let me know if that makes sense.

EDIT: In an effort to boost my post count, I will be answering all questions multiple times.

Last edited by igner (2006-01-23 13:54:30)

kit · 2006-02-04 13:27:16

Not to be picky but…

The mark-up for ign_show_login:
<code>
<label>blah<br /><input /></label>
</code>
Shouldn’t it be:
<code>
<label>blah</label><input />
</code>

Also, have you considered wrapping the login in a definition list rather than a paragraph? This seems to be quite fashionable at the moment.

OK, it was picky!

igner · 2006-02-04 20:20:27

Actually, the wrapping the input in the label is intentional – doing so creates an implicit association without having to use the “for” attribute. Nothing semantically incorrect about that particular piece of markup.

Hadn’t really thought a lot about the other markup, except to say that eventually I’d like to make as much of that as possible configurable by the end user…probably by calling a form. But that hasn’t happened yet.

photonomad · 2006-02-19 23:55:13

Hi,

For the function: ign_logged_user —- how do I alter the code (seen below in original form) so that instead of displaying the user’s name… it just displays the word “login” or “logout” ?

<code> //displays logged-in user function ign_logged_user($atts) { global $ign_user, $ign_err;

extract(lAtts(array( ‘logged_msg’ => IGN_NOT_LOGGED_IN, ‘display’ => ‘name’, ‘alt’ => IGN_LOGOUT_LINK, ‘verbose’ => false, ‘greeting’ => gtxt(‘logged_in_as’) ), $atts));

if ( !$ign_err ) { list($c_userid,$c_privs,$c_realname,$cookie_hash) = split(‘,’,$_COOKIE[‘ign_login’]); $u_display = (strtolower($display) == ‘realname’) ? $c_realname : $c_userid; $user= ($verbose) ? graf(gTxt(‘logged_in_as’).’ ‘.$u_display.br.’<a href=”?logout=1” alt=”’.$alt.’” title=”’.$alt.’”>’.gTxt(‘logout’).’</a>’) : ‘<a href=”?logout=1” alt=”’.$alt.’” title=”’.$alt.’”>’.$u_display.’</a>’; return $user; } else { return graf($logged_msg); } }
</code>

thx, stacey

Textpattern CMS

Textpattern CMS support forum

#169 2005-12-31 16:33:08

Re: ign_password_protect

#170 2006-01-16 19:35:28

Re: ign_password_protect

#171 2006-01-16 20:01:21

Re: ign_password_protect

#172 2006-01-16 20:09:28

Re: ign_password_protect

#173 2006-01-20 04:49:36

Re: ign_password_protect

#174 2006-01-20 16:02:51

Re: ign_password_protect

#175 2006-01-20 18:52:48

Re: ign_password_protect

#176 2006-01-20 19:33:52

Re: ign_password_protect

#177 2006-01-22 23:05:35

Re: ign_password_protect

#178 2006-02-04 13:27:16

Re: ign_password_protect

#179 2006-02-04 20:20:27

Re: ign_password_protect

#180 2006-02-19 23:55:13

Re: ign_password_protect

Board footer