ign_password_protect

saccade · 2006-11-25 23:48:30

I would like to have the following effect on my sites:

When viewing the public site (without a login) all authors of my sites should get an additional link in their own articles which will bring them to the edit page of their article.

As I understand so far, it is not possible to refer to an existing backend cookie, but there has to be a new login provided by ign_password_protect. So it will be necessary that the authors log in once. This could be done for example by a login in an extra article.

Since I want to have the links only for own articles I will have to place some checking routine within the txp:ign_if_logged_in-tags that checks if the logged in author equals the author of the article in question and places a link only if this is true.

My questions:

Is this a reasonable way of achieving the effect I want to have?
Could it be a function easily added within your plugin? For example a new tag <txp:ign_logged_user_edit>Link to current article's edit</txp:ign_logged_user_edit>
Is it true that there has to be a login from within ign_password_protect – or is it possible to work without an additional login and use the login-cookie created by visiting the backend?

igner · 2006-11-26 04:04:36

FireFusion wrote:

I’ll try that but won’t that mean to different places to have to update? I’ll really trying to make this as simple for the client as possible.

TXP shouldn’t be intercepting the request at all. Using .htpasswd for the authentication is simply to narrow down whether there’s something else going on there (as I mentioned, TXP shouldn’t intercept the request at all).

Mary · 2006-11-26 13:03:59

A 404 would mean that your server cannot find the directory you’re trying to load, and so it passes the request to Textpattern (who also can’t find it, because it’s not a Txp-created page). Double-check that you’re requesting the correct url.

HTTP Authentication works on the server, and should be running before Textpattern would get a chance to run. But, it’s possibly your server is doing something it isn’t supposed to. Try adding to the very top of your .htaccess:

<IfModule mod_rewrite.c>
RewriteEngine Off
</IfModule>

igner · 2006-11-26 15:50:44

saccade wrote:

I would like to have the following effect on my sites:

When viewing the public site (without a login) all authors of my sites should get an additional link in their own articles which will bring them to the edit page of their article.

As I understand so far, it is not possible to refer to an existing backend cookie, but there has to be a new login provided by ign_password_protect. So it will be necessary that the authors log in once. This could be done for example by a login in an extra article.

Since I want to have the links only for own articles I will have to place some checking routine within the txp:ign_if_logged_in-tags that checks if the logged in author equals the author of the article in question and places a link only if this is true.

My questions:

Is this a reasonable way of achieving the effect I want to have?

Could it be a function easily added within your plugin? For example a new tag <txp:ign_logged_user_edit>Link to current article's edit</txp:ign_logged_user_edit>

Is it true that there has to be a login from within ign_password_protect – or is it possible to work without an additional login and use the login-cookie created by visiting the backend?

I understand the approach. The catch is that cookies are path specific – the admin side cookie gets set for www.domain.com/textpattern (or if txp is in a subdirectory, www.domain.com/subdirectory/textpattern). As such, the cookie can only be accessed from /textpattern and it’s subdirectories, and isn’t available from the domain root. One thought would be an admin-side plugin that copies the txp_login cookie to the site root, since you’ll really need the admin cookie in place for them to login anyway. Or alternatively modify the core to write the admin cookie to the root, rather than the /textpattern directory.

saccade · 2006-11-26 15:50:51

In my txp 4.0.4-installation ign_logged_user doesn’t show the logged in users name but only the link to log out.

I’ve read that there is something in the code but couldn’t quite figure out what to do. Is this already corrected in the plugin? Or should I edit the code with one of the examples (but which)?
Any hint for me? Thank you!

saccade · 2006-11-26 21:37:20

@igner

Just in the moment I noticed your last post, which crossed with my last.

Thank you for your answer!

As I already use ign_password_protect for protecting an internal part of our site it would be ok to have a separate ign_login-article (or place/link) in the public site to login for the authors.
Once logged in I could use the ign-login-cookie for determining where to place an edit-link.

I tried to figure out how to add a link to edit page for authors of articles.
Here is what I tried:

//displays edit link for articles of logged-in users
	function ign_logged_user_editlink($atts) {
		global $ign_user, $ign_err, $thisarticle;
		extract(lAtts(array(
			'linktext' => "Edit article",
			'linkclass' => "editlink",
		), $atts)); 
		if ( !$ign_err ) {
			list($c_userid,$c_privs,$c_realname,$cookie_hash) = split(',',$_COOKIE['ign_login']); // — determine what text needs to be displayed 
			if ($c_userid == $thisarticle['authorid']) {
			$ed_link = '<a class="'.$linkclass.'" href="'.hu.'textpattern/index.php?event=article&amp;step=edit&amp;ID='.$thisarticle['thisid'].'">'.$linktext.'</a>';
			return $ed_link; 
			}
		} 
	}

Usage:
<txp:ign_logged_user_editlink />
There are the attributes “linktext” and “linkclass”.

This will post a link to an articles edit page to the author if he is logged in.
(I didn’t plan to include different permissions – e.g. link for all articles for the admin – for I only wanted to ease editing their own articles for authors.)

Does it make sense and is it correctly coded?
Or will it produce conflicts or security issues?

saccade · 2006-11-27 08:28:09

I added a small refinement to the editlink:

Now there are two additional attributes:

logout
If defined it will output a link to log out after the edit-link (with the linktext in the attribute).
The link has a class “logout…” with the linkclass-definition.

sep
will provide the separating text between editlink and logoutlink. The default is a space.

If logout is not defined, no logout-link will be placed.

For me this makes sense in sites, where normally no login is necessary, but if logged in authors can see editlinks to their own articles.
If they want to get rid of these links (or to login with another authorship), they can logout.

	//displays edit link for articles of logged-in users
	function ign_logged_user_editlink($atts) {
		global $ign_user, $ign_err, $thisarticle;

		extract(lAtts(array(
			'linktext' => "Edit article",
			'linkclass' => "editlink",
			'sep' => " ",
			'logout' => false,
		), $atts)); 

		if ( !$ign_err ) {
			list($c_userid,$c_privs,$c_realname,$cookie_hash) = split(',',$_COOKIE['ign_login']); // — determine what text needs to be displayed 
			if ($c_userid == $thisarticle['authorid']) {
			$ed_link = '<a class="'.$linkclass.'" href="'.hu.'textpattern/index.php?event=article&amp;step=edit&amp;ID='.$thisarticle['thisid'].'">'.$linktext.'</a>';
				if ($logout != false) {
				$ed_link .= $sep . '<a class="logout' . $linkclass . '" href="' . $_SERVER['REQUEST_URI']. '?logout=1">' . $logout . '</a>'; 
				}
			return $ed_link; 
			}
		} 
	}

Last edited by saccade (2006-11-27 08:28:28)

FireFusion · 2006-11-27 12:27:06

Mary wrote:

A 404 would mean that your server cannot find the directory you’re trying to load, and so it passes the request to Textpattern (who also can’t find it, because it’s not a Txp-created page). Double-check that you’re requesting the correct url. HTTP Authentication works on the server, and should be running before Textpattern would get a chance to run. But, it’s possibly your server is doing something it isn’t supposed to. Try adding to the very top of your .htaccess:

<IfModule mod_rewrite.c>
RewriteEngine Off
</IfModule>

Ok, I try that and it didn’t work still. I also tried setting it up on a different directory and server and I got a 500 Internal Server Error.

I Think there is something else wrong. Has anyone else tried to do it yet?

Last edited by FireFusion (2006-11-27 12:30:44)

igner · 2006-11-27 14:58:05

saccade – looks good. I don’t see anything in there that will cause problems. I would simplifiy the test on $logout – since it’s a boolean, just use the value itself. Instead of

if ($logout != true)

you can use

if (!$logout)

They are effectively the same thing. But aside from shaving seven characters, it’s probably really only a matter of preference.

Last edited by igner (2006-11-28 04:56:46)

igner · 2006-11-27 17:49:06

FireFusion wrote:

Ok, I try that and it didn’t work still. I also tried setting it up on a different directory and server and I got a 500 Internal Server Error.

I Think there is something else wrong. Has anyone else tried to do it yet?

@FireFusion – when you say “it didn’t work”, what didn’t work?

As I see it, there are two issues that need to be resolved:

accessing the non-txp directories
password protecting the non-txp directories

If you disabled mod_rewrite, and got an error, comment out your authentication code in .htaccess, and make sure that you can get to the content in that directory. Sort out the mod_rewrite stuff, then come back to the password protection.

Next step is determining which version of Apache is running, and whether mod_auth_mysql is available. I did some digging, and it looks like there’s no version of mod_auth_mysql for Apache 2.2.

All that being said, there were some errors in the .htaccess you posted (at least for the most current version of mod_auth_mysql from sourceforge); the following worked for me locally after installing mod_auth_mysql 3.0:

AuthType Basic
AuthName "MySQL Member Page"

AuthMySQLEnable On
AuthMYSQLHost localhost
AuthMYSQLUser mydbuser
AuthMYSQLPassword mydbpassword
AuthMYSQLDB txp_dev
AuthMYSQLUserTable ign_users
AuthMYSQLNameField name
AuthMYSQLPasswordField pass
AuthMYSQLPwEncryption scrambled
require valid-user

Note the case sensitivity, and lack of underscores in the directives, but I didn’t dig too far to figure out in which revision the directives changed. So the short answer is it’s possible to authenticate against that user table, but you’re going to have to do the legwork on the other issues (and to determine whether the mod_auth_mysql route is even an option).

Edit: There may be a version available for Apache 2.2 at http://www.heuer.org/mod_auth_mysql/ – but I’m not running Apache 2 on my dev box, so I didn’t test that version…though looking at it, the syntax appears to be the same as I listed here.

Last edited by igner (2006-11-27 18:08:59)

FireFusion · 2006-11-28 11:16:40

Thanks for taking such an interest in this igner. That is encouraging to know you got it working locally.

I’ve tried it on Dreamhost and Textdrive so far but no luck. Have sent a support ticket to TXD asking if mod_auth_mysql is installed but no reply yet. I always get a Textpattern 404 error even if I add this to the top of the .htaccess file in the folder…

<IfModule mod_rewrite.c>
RewriteEngine Off
</IfModule>

If I remove the .htaccess from the folder completely I can access it as normal without TXP redirecting me.

Also If I remove the TXP’s .htaccess file from the root of my site I get 500 Internal Server Error when I try to access the folder.

And finally I tried the .htpasswd and got that working, but of course that isn’t what I want.

igner · 2006-11-28 14:03:49

FireFusion wrote:

Thanks for taking such an interest in this igner. That is encouraging to know you got it working locally.

I’ve tried it on Dreamhost and Textdrive so far but no luck. Have sent a support ticket to TXD asking if mod_auth_mysql is installed but no reply yet. I always get a Textpattern 404 error even if I add this to the top of the .htaccess file in the folder…

I suspect the TXD staffers are pretty buried, in that I think they’re working to move all the shared hosting over to Solaris containers this month. I tried on Burnaby, but it doesn’t appear to have mod_auth_mysql installed. Then again, I think Burnaby’s running Apache 2.2.

If I remove the .htaccess from the folder completely I can access it as normal without TXP redirecting me.

That still strikes me as weird – even with an .htaccess file in the directory, if you’re accessing an existing resource, the rewrite rules in the parent folder shouldn’t come into play. Is there something else in that .htaccess file that might be causing a redirect?

Textpattern CMS

Textpattern CMS support forum

#277 2006-11-25 23:48:30

Re: ign_password_protect

#278 2006-11-26 04:04:36

Re: ign_password_protect

#279 2006-11-26 13:03:59

Re: ign_password_protect

#280 2006-11-26 15:50:44

Re: ign_password_protect

#281 2006-11-26 15:50:51

Re: ign_password_protect

#282 2006-11-26 21:37:20

Re: ign_password_protect

#283 2006-11-27 08:28:09

Re: ign_password_protect

#284 2006-11-27 12:27:06

Re: ign_password_protect

#285 2006-11-27 14:58:05

Re: ign_password_protect

#286 2006-11-27 17:49:06

Re: ign_password_protect

#287 2006-11-28 11:16:40

Re: ign_password_protect

#288 2006-11-28 14:03:49

Re: ign_password_protect

Board footer