Wintermute
New member
Hello. I am a user at one of the forums that recently purchased and started using DBSeo, although I am not the admin. I do know that it's 3.8.x vBulletin. I can ask for the exact version -- probably the latest patch there is, I don't think it matters. I've also replicated this exact problem in my own test setup on my PC with vBulletin 3.8.7, so I wrote in this version.
There are problems with some of the external urls in posts, when Anonymize External URLS is set to YES and the url has symbols: & '
So, since I am also a coder myself, I've downloaded DBSEO lite to look at the code, and I think I might have found where this problem is coming from.
In url.php:
In dbseo.php - for some reason it does not let me paste this snippet here in any way I try (size limit?), so, see if (DBSEO_URL_QUERY_FILE == 'redirect-to/') { $redirectUrl = str_replace(a - Pastebin.com
There are 2 of what I believe to be bugs
1) (url.php) Through a little bit of hacking, I've established that when it reaches that code in url.php, if there was an apostrophe in the url, in the $url variable it is at this point represented by html entity & # 39 ; The existing code seemed to try to remove entities, but it will not remove this one, and neither did get_html_translation_table(HTML_ENTITIES, ENT_QUOTES | ENT_HTML401) when I tried it, because the latter only has 039 (the difference is in leading zero). Something like this can decode this html entity back to the ASCII apostrophe character:
When I changed url.php code this way, it takes care of the url with apostrophe problem in my test setup. Maybe there is a more optimal way, this is just something I've seen working.
2) (dbseo.php) There is a second, independent problem, in dbseo.php. In some of these string replacements / regular expression replacements going on. Looks to me they might convert " and & to the corresponding html entity. But I think this is invalid, because afterwards this will be written to HTTP header value, which is *not HTML*, therefore html entities should not be in it. So perhaps the line should be replaced with the following?
Making this change takes care of the problem with ampersands in urls. The way I read HTTP specs # 4.2 Message Headers, it's valid without those string replacements.
======
Two of the test urls I used, that did NOT redirect properly in my test setup, but do work after the above 2 code changes.
https://translate.google.com/translate?hl=en&ie=UTF8&prev=_t&sl=ru&tl=en&u=http://lenta.ru/
http://en.wikipedia.org/wiki/Ukrainian_People's_Republic
Hope this might be of some help in finding and fixing anonymizing/redirect feature with these kinds of urls.
There are problems with some of the external urls in posts, when Anonymize External URLS is set to YES and the url has symbols: & '
So, since I am also a coder myself, I've downloaded DBSEO lite to look at the code, and I think I might have found where this problem is coming from.
In url.php:
PHP:
// Ensure external URLs have redirects
$url = DBSEO::$config['_bburl'] . '/redirect-to/?redirect=' . urlencode(strtr($url, array_flip(get_html_translation_table(HTML_ENTITIES))));
In dbseo.php - for some reason it does not let me paste this snippet here in any way I try (size limit?), so, see if (DBSEO_URL_QUERY_FILE == 'redirect-to/') { $redirectUrl = str_replace(a - Pastebin.com
There are 2 of what I believe to be bugs
1) (url.php) Through a little bit of hacking, I've established that when it reaches that code in url.php, if there was an apostrophe in the url, in the $url variable it is at this point represented by html entity & # 39 ; The existing code seemed to try to remove entities, but it will not remove this one, and neither did get_html_translation_table(HTML_ENTITIES, ENT_QUOTES | ENT_HTML401) when I tried it, because the latter only has 039 (the difference is in leading zero). Something like this can decode this html entity back to the ASCII apostrophe character:
PHP:
$url = DBSEO::$config['_bburl'] . '/redirect-to/?redirect=' . urlencode(html_entity_decode($url, ENT_QUOTES | ENT_HTML401));
2) (dbseo.php) There is a second, independent problem, in dbseo.php. In some of these string replacements / regular expression replacements going on. Looks to me they might convert " and & to the corresponding html entity. But I think this is invalid, because afterwards this will be written to HTTP header value, which is *not HTML*, therefore html entities should not be in it. So perhaps the line should be replaced with the following?
PHP:
$redirectUrl = $_GET['redirect'];
======
Two of the test urls I used, that did NOT redirect properly in my test setup, but do work after the above 2 code changes.
https://translate.google.com/translate?hl=en&ie=UTF8&prev=_t&sl=ru&tl=en&u=http://lenta.ru/
http://en.wikipedia.org/wiki/Ukrainian_People's_Republic
Hope this might be of some help in finding and fixing anonymizing/redirect feature with these kinds of urls.