[jrothra]

Originally Posted by Simon

About the return issue...it should be nothing to do with xmlhttp, the return value should always be relative. So instead of return=http://www.faithtag.com/ it should be return=/ - at least that's the way I see it. I thought Pligg would do that for you automatically anyway when redirecting to a login page using the return value.

When you try voting on the site, www.faithtag.com, what URL does it send you to?

[jrothra]

I just ran a test on my site and noticed something interesting:
1. I created a test user account.
2. Once logged in, I tried voting on the story.

The vote went through fine. So, the 406 error only occurs when you're not logged on.

[Simon]

Just looking at your test with the blog, the full error is:

Not Acceptable
An appropriate representation of the requested resource /evb/url.php could not be found on this server.

Apache/1.3.37 Server at www.faithtag.com Port 80

I've never come across an error like that before with apache, do you have anymore info on it? I'll search around and see if I can dig anything up on it.

[Simon]

One common source of the error seems to be hosts that enable mod_security too strictly. Could you try this code at the top of your htaccess file for starters: (taken from this blog article on 406 errors)

<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>

[jrothra]

Here's what's in the .htaccess file (including what you recommended):

<IfModule mod_security.c>
SecFilterEngine Off
SecFilterScanPOST Off
</IfModule>

# BEGIN WordPress
<IfModule mod_rewrite.c>
RewriteEngine On
RewriteBase /blog/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule . /blog/index.php
</IfModule>

# END WordPress

I've tried placing the first part after "END WordPress," before "BEGIN WordPress," and between those two. No difference.

[jrothra]

I sent an email to the webhost for both of the sites (faithtag.com and jrothraministries.com) to ask them. Both sites are hosted by the same company. Maybe they might be able to tell us something.

[jrothra]

Got a response from the webhost...

We've been running mod_security for a long time now, and it doesn't like embedded http urls in the query string, as that is how most cross-site scripting exploits are done.

I remember I had a problem with an RSS feed from ChristianityToday.com on my main website (www.jrothraministries.com) because the rss2html system used the full http:// URL. One of their techs altered the RSS2HTML system to have it pull the feed but not use the full http:// URL. It was over a year ago so I don't remember (nor could I find) what they did.

So, the problem is they don't allow the http:// in the URL. So, the EVB and non-logged-in voting, which I suppose are pulling using the full http:// URL will not work.

I checked the URL's that voting when not logged in send me to and the EVB and both have the full http:// in the referer. Taking out the http:// works. So, while the system should be dynamic, it is somehow, for some reason, using the full protocol domain. Is there a way to alter that?

Also, the .htaccess hack didn't work, probably because their security feature overrides it.

I've asked them what they did with the RSS2HTML system on my site to have it work... awaiting a reply.

[Simon]

I quickly added in a new variable called $url_mod - it will remove the http:// from the querystring url. It might take some more effort to get it working though, as it would potentially require you to make sure that all submission urls have http:// removed when being saved in the database.

[mvandemar]

Originally Posted by Simon

I quickly added in a new variable called $url_mod - it will remove the http:// from the querystring url. It might take some more effort to get it working though, as it would potentially require you to make sure that all submission urls have http:// removed when being saved in the database.

Simon,

In button.php, modify the following code:

function pliggit() {
	var check = window.parent.submit_url;
	if(!check) { 
		var url1 = document.URL; 
	} else { 
		var url1 = window.parent.submit_url; 
	}
	var url2 = '<?php echo $server; ?>/evb/url.php?url='+url1;
	document.write('<iframe name="pliggit" width="54" height="71" scrolling="no" frameborder="0" src="'+url2+'"></iframe>');
}

to look like this:

function pliggit() {
	var check = window.parent.submit_url;
	if(!check) { 
		var url1 = document.URL; 
	} else { 
		var url1 = window.parent.submit_url; 
	}
	url1 = url1.replace(http:\/\//i,'');
	var url2 = '<?php echo $server; ?>/evb/url.php?url='+url1;
	document.write('<iframe name="pliggit" width="54" height="71" scrolling="no" frameborder="0" src="'+url2+'"></iframe>');
}

-Michael

[mvandemar]

Ok, just checked on the demo... it looks like they have it so that (in the demo anyways) it rejects a url as invalid when there is no http:// at the beginning. As Digg (and other social networking sites), and instead automatically append the missing protocol, I think Pligg should probably be modified to do the same. It's a quick check to see if the user left it off, and should really be standard to add it for them if so.

Now, I didn't dig into the code behind it, I am just going by the behavior on the demo site.

-Michael