ign_password_protect

zensir · 2006-08-30 13:51:46

thanks a lot for your answer, you are doing a great job!!
keep on going!
greetings

gerhard · 2006-09-01 11:17:45

Hi, downloaded the latest ign_password_protect (0.4.2d) and SVNed to TXP 4.0.3 r1792 and I keep getting these errors when going into extensions > ign_user_mgmt:

<pre>
Notice: Unknown tag attribute: prefs_id in /Library/WebServer/Documents/offline/dma/textpattern/lib/txplib_misc.php on line 582
Notice: Unknown tag attribute: sitename in /Library/WebServer/Documents/offline/dma/textpattern/lib/txplib_misc.php on line 582
Notice: Unknown tag attribute: siteurl in /Library/WebServer/Documents/offline/dma/textpattern/lib/txplib_misc.php on line 582
Notice: Unknown tag attribute: site_slogan in /Library/WebServer/Documents/offline/dma/textpattern/lib/txplib_misc.php on line 582
Notice: Unknown tag attribute: language in /Library/WebServer/Documents/offline/dma/textpattern/lib/txplib_misc.php on line 582
Notice: Unknown tag attribute: url_mode in /Library/WebServer/Documents/offline/dma/textpattern/lib/txplib_misc.php on line 582
.
.
.
</pre>

Any idea where the problem lies igner?

Cheers, Gerhard.

fmcdavid · 2006-09-08 18:31:04

Hi all,

I’m new to textpattern (and, therefore, this plugin), but in poking around trying to figure out why ign_logged_user was acting up, I found a spot where I thought I might be able to contribute.

The code is below. It should now act as the docs indicate and I added an attribute called “logoutlink” [true|false] that I think might be useful from time to time.

Any copyright privileges on the code below is hereby transferred to Jeremy Amos to do with as he sees fit.

—Fred

<pre>
<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’), ‘logoutlink’ => 0 ), $atts)); if ( !$ign_err ) { list($c_userid,$c_privs,$c_realname,$cookie_hash) = split(‘,’,$_COOKIE[‘ign_login’]); // — determine what text needs to be displayed $u_display = “Log Out”; switch(strtolower($display)) { case ‘realname’: $u_display = $c_realname; break; case ‘name’: $u_display = $c_userid; break; } $user = $u_display; if ($logoutlink) { $user = “<”.“a href=’”.$_SERVER[‘REQUEST_URI’].”?logout=1’>$user<”.”/a>”; } if ($verbose) { $user = graf(gTxt(‘logged_in_as’).’ ‘.$user.br); } return $user; } else { return graf($logged_msg); } }

</code>
</pre>

fmcdavid · 2006-09-08 18:41:38

oops…you might also want to change the default for the ‘display’ param to ‘logout’ and for the ‘logoutlink’ to ‘true’ to ensure that the default behavior is the same as it was before I got to monkeying around with it.

updated code:

<pre>
<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’ => ‘logout’, ‘alt’ => IGN_LOGOUT_LINK, ‘verbose’ => false, ‘greeting’ => gtxt(‘logged_in_as’), ‘logoutlink’ => true ), $atts)); if ( !$ign_err ) { list($c_userid,$c_privs,$c_realname,$cookie_hash) = split(‘,’,$_COOKIE[‘ign_login’]); // — determine what text needs to be displayed $u_display = “Log Out”; switch(strtolower($display)) { case ‘realname’: $u_display = $c_realname; break; case ‘name’: $u_display = $c_userid; break; } $user = $u_display; if ($logoutlink) { $user = “<” . “a href=’”.$_SERVER[‘REQUEST_URI’].”?logout=1’>$user</a>”; } if ($verbose) { $user = graf(gTxt(‘logged_in_as’).’ ‘.$user.br); } return $user; } else { return graf($logged_msg); } } </code> </pre>

igner · 2006-09-08 19:04:17

@Gerhard – hmm, didn’t get notification on that post (and haven’t spent a lot of time on the forums lately), so sorry I missed your post. Not sure what’s going on there, since there shoudn’t be any tag parsing going on in the admin side. I’ve tested 0.4d with r1796 (and zem’s proposed admin side tweaks), and I’m not seeing a problem. Might be a conflict with another plugin? Let me know if you’re still seeing the issue.

@Fred – er, right, thanks for that. Just for the record (and because I don’t really have the time at the moment to look at it) – what was the broken behaviour that this fixes?

fmcdavid · 2006-09-08 19:34:03

Hi Jeremy,

The function ign_logged_user was mostly all commented out. It was hard coded to provide only a “Log Out” link (if the user was logged in). There was no way to actually get the the login name using ign_logged_user as it was coded.

I just played around with what was commented out to get the functionality I needed and then went back to make sure it could still provide the “Log Out” link.

If you had it commented out for security purposes, then I probably just opened the hole back up. :)

I’ve done a little testing and things seem to work ok. Code is pretty straightforward.

The version I have is: 0.4.2d

Thanks for writing this plugin, btw. For my purposes, Textpattern is much nicer with it than without.

—Fred

fmcdavid · 2006-09-08 19:41:45

To be more complete, here’s the original code (there was other code in there that was commented out, but functionally, this was it) plus some concat operators in the href building code (to make it readable in this post)::

—Fred

<pre>
<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 ) { return “<”.“a href=’”.$_SERVER[‘REQUEST_URI’].”?logout=1’>Log Out<”.”/a>”; } else { return graf($logged_msg); } }

</code>
</pre>

igner · 2006-09-08 19:44:17

ah, yes. I see what’s going on. I forget why I did that (I think someone asked about how to make that happen). I clearly forgot to revert that block of code when I was done. I’d talk with the QA team, but she started first grade this week, so the added stress might make her cry. And we don’t want that :)

Thanks for posting the fix. I’ll try and get that worked back into the source this weekend.

fmcdavid · 2006-09-08 20:20:56

On another topic, I’d like to try to secure whole sections. I see there’s some issues regarding sections/urls and rss feeds.

Would it be enough to simply disallow rss on the section and write a plugin that would, in the article display form, let me:
<pre>
<code>
<txp:xxx_if_current_section_matches_article_section> …show stuff…
<txp:else> …complain or do nothing…
</txp:xxx_if_current_section_matches_article_section>
</code>
</pre>

Since I’m new to textpattern, I’m mostly wondering if this would take care of the issues around password protecting entire sections or am I missing some key bit of knowledge that would have me spinning my wheels on a moot point?

Thoughts?

—Fred

Last edited by fmcdavid (2006-09-08 20:23:36)

igner · 2006-09-08 21:16:23

In the case of this plugin, what you’ve described is what the pluing does – it grabs the enclosed content, then displays it based on credentials presented. In other words, it’s protecting the content in-line. In the case of the RSS feeds, the tags aren’t parsed, so there’s no way to protect the content.

I’ve been mentally sketching out a couple of approaches to protecting content at the section level, in part because there have been numerous requests to handle redirects on login (for things like client-only areas). There are a number of catches (the RSS & File Downloads being two of them), but I think I’ve sort of worked out how I can make this happen…now it’s just a matter of finding the time to write the code :)

fmcdavid · 2006-09-11 14:49:57

What I was getting at is whether a (hopefully easy to write) complementary tag might be a quick fix to allow secured sections.

What I meant to ask was: if the following were in the article display form, would it handle the url issues (assuming that RSS were disabled for the section)?

<pre><code><txp:ign_if_logged_in>
<txp:xxx_if_current_section_matches_article_section> …show stuff…
<txp:else> …complain or do nothing…
</txp:xxx_if_current_section_matches_article_section>
</txp:ign_if_logged_in></code></pre>

But, now that I’m looking at it again, it would appear that I could get pretty close if I simply did:

<pre><code><txp:if_section name=“seca,secb,secc”>
<txp:ign_if_logged_in> …show stuff…
</txp:ign_if_logged_in>
<txp:else> …complain or do nothing…
</txp:if_section></code></pre>

Would this allow for secured sections (assuming disabled RSS on seca,secb, and secc) or would there still be another reason to worry about security on an article-by-article basis?

For that matter, could a similar approach be used to secure categories?

—Fred

fmcdavid · 2006-09-11 15:52:19

I just tried securing categories with if_category and ign_if_logged in in the article display form and it seems to work very well. I’d be curious to know how it might be circumvented.

—Fred

Textpattern CMS

Textpattern CMS support forum

#241 2006-08-30 13:51:46

Re: ign_password_protect

#242 2006-09-01 11:17:45

Re: ign_password_protect

#243 2006-09-08 18:31:04

Re: ign_password_protect

#244 2006-09-08 18:41:38

Re: ign_password_protect

#245 2006-09-08 19:04:17

Re: ign_password_protect

#246 2006-09-08 19:34:03

Re: ign_password_protect

#247 2006-09-08 19:41:45

Re: ign_password_protect

#248 2006-09-08 19:44:17

Re: ign_password_protect

#249 2006-09-08 20:20:56

Re: ign_password_protect

#250 2006-09-08 21:16:23

Re: ign_password_protect

#251 2006-09-11 14:49:57

Re: ign_password_protect

#252 2006-09-11 15:52:19

Re: ign_password_protect

Board footer