forum.coppermine-gallery.net
No Support => Modifications/Add-Ons/Hacks => Mods: Miscellaneous => Topic started by: Ludo on March 11, 2009, 05:15:08 pm
-
[ Edit: scroll down for the effective hack - Ludo ]
I've finally accomplished a workaround to sanitize only BBCode containing exploits addressed by 1.4.21. (http://forum.coppermine-gallery.net/index.php/topic,58265.0.html)
This hack will strip only img and url BBCode tags containing http://[host]/[path]/delete.php, supposing that exploits rely on executing that file (please let me know if I'm wrong).
OPEN
include/functions.php
FIND (in function bb_decode)
static $bbcode_tpl = array();
BEFORE, ADD
global $CONFIG;
FIND
return $text;
BEFORE, ADD
if (strpos($text, $CONFIG['ecards_more_pic_target']."delete.php") !== false) $text = strip_tags($text, "<b><u><i><span>");
SAVE AND CLOSE
-
please let me know if I'm wrong
You're wrong: do what you suggested and I'll hack your site in less than a minute. Reason: you can't sanitize against redirection. What should keep me from settings up a redirect (e.g. by using tinyurl or similar services) that points to delete.php on your server. The URI will look innocent, so you can't sanitize it. The only way of sanitizing properly would be allowing only local images and URLs (from the domain the gallery runs on), assuming that you have control over redirects on your server. This would of course not be true for freehost, where you run on subdomains like http://example.free.fr
-
you can't sanitize against redirection.
Sigh, I didn't figure out that way of hacking... :-[ :'(
It looked too easy to work out... ;D
-
I tried successfully a different approach, which - as far as I tested - ensures protection from mentioned exploits without any inconvenience concerning gallery functionality.
Basically, it relies on switching main form (editForm) in usermgr.php from GET to POST method, and then checking for $_POST instead of $_GET/$_REQUEST in delete.php when change_group or add_group action is triggered. This prevents from any request sent by query string to get executed.
When applying this patch to v. 1.4.21 and newer, you must restore previous version of bb_decode function in include/functions.inc.php, by replacing actual version with code below:
function bb_decode($text)
{
$text = nl2br($text);
static $bbcode_tpl = array();
static $patterns = array();
static $replacements = array();
// First: If there isn't a "[" and a "]" in the message, don't bother.
if ((strpos($text, "[") === false || strpos($text, "]") === false))
{
return $text;
}
// [b] and [/b] for bolding text.
$text = str_replace("[b]", '<b>', $text);
$text = str_replace("[/b]", '</b>', $text);
// [u] and [/u] for underlining text.
$text = str_replace("[u]", '<u>', $text);
$text = str_replace("[/u]", '</u>', $text);
// [i] and [/i] for italicizing text.
$text = str_replace("[i]", '<i>', $text);
$text = str_replace("[/i]", '</i>', $text);
// colours
$text = preg_replace("/\[color=(\#[0-9A-F]{6}|[a-z]+)\]/", '<span style="color:$1">', $text);
$text = str_replace("[/color]", '</span>', $text);
// [i] and [/i] for italicizing text.
//$text = str_replace("[i:$uid]", $bbcode_tpl['i_open'], $text);
//$text = str_replace("[/i:$uid]", $bbcode_tpl['i_close'], $text);
if (!count($bbcode_tpl)) {
// We do URLs in several different ways..
$bbcode_tpl['url'] = '<span class="bblink"><a href="{URL}" rel="external">{DESCRIPTION}</a></span>';
$bbcode_tpl['email']= '<span class="bblink"><a href="mailto:{EMAIL}">{EMAIL}</a></span>';
$bbcode_tpl['url1'] = str_replace('{URL}', '\\1\\2', $bbcode_tpl['url']);
$bbcode_tpl['url1'] = str_replace('{DESCRIPTION}', '\\1\\2', $bbcode_tpl['url1']);
$bbcode_tpl['url2'] = str_replace('{URL}', 'http://\\1', $bbcode_tpl['url']);
$bbcode_tpl['url2'] = str_replace('{DESCRIPTION}', '\\1', $bbcode_tpl['url2']);
$bbcode_tpl['url3'] = str_replace('{URL}', '\\1\\2', $bbcode_tpl['url']);
$bbcode_tpl['url3'] = str_replace('{DESCRIPTION}', '\\3', $bbcode_tpl['url3']);
$bbcode_tpl['url4'] = str_replace('{URL}', 'http://\\1', $bbcode_tpl['url']);
$bbcode_tpl['url4'] = str_replace('{DESCRIPTION}', '\\2', $bbcode_tpl['url4']);
$bbcode_tpl['email'] = str_replace('{EMAIL}', '\\1', $bbcode_tpl['email']);
// [url]xxxx://www.phpbb.com[/url] code..
$patterns[1] = "#\[url\]([a-z]+?://){1}([a-z0-9\-\.,\?!%\*_\#:;~\\&$@\/=\+\(\)]+)\[/url\]#si";
$replacements[1] = $bbcode_tpl['url1'];
// [url]www.phpbb.com[/url] code.. (no xxxx:// prefix).
$patterns[2] = "#\[url\]([a-z0-9\-\.,\?!%\*_\#:;~\\&$@\/=\+\(\)]+)\[/url\]#si";
$replacements[2] = $bbcode_tpl['url2'];
// [url=xxxx://www.phpbb.com]phpBB[/url] code..
$patterns[3] = "#\[url=([a-z]+?://){1}([a-z0-9\-\.,\?!%\*_\#:;~\\&$@\/=\+\(\)]+)\](.*?)\[/url\]#si";
$replacements[3] = $bbcode_tpl['url3'];
// [url=www.phpbb.com]phpBB[/url] code.. (no xxxx:// prefix).
$patterns[4] = "#\[url=([a-z0-9\-\.,\?!%\*_\#:;~\\&$@\/=\+\(\)]+)\](.*?)\[/url\]#si";
$replacements[4] = $bbcode_tpl['url4'];
// [email]user@domain.tld[/email] code..
$patterns[5] = "#\[email\]([a-z0-9\-_.]+?@[\w\-]+\.([\w\-\.]+\.)?[\w]+)\[/email\]#si";
$replacements[5] = $bbcode_tpl['email'];
// [img]xxxx://www.phpbb.com[/img] code..
$bbcode_tpl['img'] = '<img src="{URL}" alt="" />';
$bbcode_tpl['img'] = str_replace('{URL}', '\\1\\2', $bbcode_tpl['img']);
$patterns[6] = "#\[img\]([a-z]+?://){1}([a-z0-9\-\.,\?!%\*_\#:;~\\&$@\/=\+\(\)]+)\[/img\]#si";
$replacements[6] = $bbcode_tpl['img'];
}
$text = preg_replace($patterns, $replacements, $text);
return $text;
}
Is there in this perspective any security hole or operation fault I didn't notice? Anyway, here is the mod:
OPEN
usermgr.php
FIND
print '<form method="get" action="delete.php" name="editForm">'."\n";
CHANGE TO
print '<form method="post" action="delete.php" name="editForm">'."\n";
OPEN
delete.php
FIND
$user_id = str_replace('u', '', $_GET['id']);
CHANGE TO
$user_id = str_replace('u', '', $_POST['id']);
FIND (line 673)
// set this user's group
BEFORE, ADD
if (isset($_POST['group'])) {
FIND (5 times)
$_REQUEST['group']
CHANGE TO
$_POST['group']
FIND (line 678)
print '</b></td>';
REPLACE WITH
}
print '</td>';
SAVE AND CLOSE ALL FILES
-
Basically, it relies on switching main form (editForm) in usermgr.php from GET to POST method, and then checking for $_POST instead of $_GET/$_REQUEST in delete.php when change_group or add_group action is triggered. This prevents from any request sent by query string to get executed.
As suggested in this old article--> http://shiflett.org/articles/cross-site-request-forgeries (http://shiflett.org/articles/cross-site-request-forgeries)
When the exploit was posted in this forum I read a little bit about CSRF. I didn't quote that article because I thought there is missing point there. (I'm not programmer, I don't know the missing point...just wondering) I mean, I don't think that such and old solution would fill that hole, right Devs? ???
-
That is more advanced than anything I would think about...
I just upgraded to 1.4.21 (nice work on a quick release, guys) and then discovered my links gone (and then the reasoning).
What I'm wondering is am I vulnerable on a non-multiuser site? My thought is that if I have comments turned on then yes, so what I'm thinking of doing until a more elegant solution is found is having an alternate bb_decode function for album descriptions.
I encode links in my album descriptions where there is a relevant blog posting and since it is a closed system, there should be no way for an outside user to create an album and use this exploit. Meanwhile, comments will still not include link or image tags as they used to, but I'm ok with that anyway.
Thoughts?
-
@Ludo: that's part of the correct approach that needs looking into in detail. Thanks for providing your suggestions.
However, as suggested in the article that Fabricio refered to,POST requests can also be forged, so do not consider a strict use of $_POST to be sufficient protection.
This being said: using POST would be better than using GET, but this would not completely solve the problem, but only would make it a bit harder to come up with a working exploit.
The real solution is to make sure that the actual form has been used and that it was submit on purpose. This can be accomplished using a session token, as described in the article.
@Fabricio: thanks for providing that article - I haven't read it before, but it describes exactly what we're trying to do as a permanent counter-measure against CSRF.
@cof: as suggested in other threads: if you're the only user of your gallery (i.e. the only person who could use bbcode), you can savely uncomment the security fixes from cpg1.4.21 and allow usage of the missing bbocde tags, as you'll be the only person capable of using them. There's no hidden exploit that we're aware of that could be used against you in that environment.
Once again: if another user or guest can post/publish anything on your gallery (be it a comment or a file he could upload or a personal gallery that he could create from within the coppermine user interface), you'd be vulnerable if you allowed the bbcode tags [ i m g ] and [ u r l ]. In that situation, you mustn't uncomment the fixes performed in include/functions.inc.php.
Only if you can be absolutely sure that there can be no user interaction as far as using those potentially dangerous bbcodes are concerned, it's safe to re-allow those bbcodes.
-
@Fabricio: thanks for providing that article - I haven't read it before, but it describes exactly what we're trying to do as a permanent counter-measure against CSRF.
I'm happy to hear it. I thought you were aware of it. Anyways, maybe it helps a little bit to dev team to find a final solution to CSRF issue. ;)
-
@Ludo: that's part of the correct approach that needs looking into in detail. Thanks for providing your suggestions.
You're welcome, I worked it out for my sake ;)
However, as suggested in the article that Fabricio refered to,This being said: using POST would be better than using GET, but this would not completely solve the problem, but only would make it a bit harder to come up with a working exploit.
The real solution is to make sure that the actual form has been used and that it was submit on purpose. This can be accomplished using a session token, as described in the article.
Sure, and I think it could be done relatively easily. Well, instead of using session tokens, I early figured out to extend captcha mod to usermgr.php: I could resume working on it.
But in this theoretical perspective, each and every form would need to be secured against potential forging, while - practically speaking - no CPG forms forging exploit is known so far, isn'it it? Then, if my fix can address the actual exploits without losing BBCode img and url tags, isn't this - at present - a better balance between security and functionality?
-
The reports of exploits will start rolling in soon probably.
-
Shouldn't it be enough to disable bbcode processing of the tags 'url' and 'img' for admins in admin mode only?
I don't know which forms for 'regular' users are affected by this exploid. Maybe an attacker can delete some comments or pictures/albums from a particular user?
If the exploit affects admins only, here my suggestion:
function bb_decode($text)
{
$text = nl2br($text);
static $bbcode_tpl = array();
static $patterns = array();
static $replacements = array();
// First: If there isn't a "[" and a "]" in the message, don't bother.
if ((strpos($text, "[") === false || strpos($text, "]") === false))
{
return $text;
}
// [b] and [/b] for bolding text.
$text = str_replace("[b]", '<b>', $text);
$text = str_replace("[/b]", '</b>', $text);
// [u] and [/u] for underlining text.
$text = str_replace("[u]", '<u>', $text);
$text = str_replace("[/u]", '</u>', $text);
// [i] and [/i] for italicizing text.
$text = str_replace("[i]", '<i>', $text);
$text = str_replace("[/i]", '</i>', $text);
// colours
$text = preg_replace("/\[color=(\#[0-9A-F]{6}|[a-z]+)\]/", '<span style="color:$1">', $text);
$text = str_replace("[/color]", '</span>', $text);
// [i] and [/i] for italicizing text.
//$text = str_replace("[i:$uid]", $bbcode_tpl['i_open'], $text);
//$text = str_replace("[/i:$uid]", $bbcode_tpl['i_close'], $text);
if (!count($bbcode_tpl)) {
// We do URLs in several different ways..
if (!GALLERY_ADMIN_MODE) {
$bbcode_tpl['url'] = '<span class="bblink"><a href="{URL}" rel="external">{DESCRIPTION}</a></span>';
} else {
// **** WARNING *******************************************************
// The [url] tag can be used for a serious attack against your website.
// So [url] tags are no longer processed to show links.
// This simple action here is not an ideal solution but is necessary.
// Now, [url] tags are processed as follows:
// [url=link]text[/url] shows 'text' with a dummy image for the link.
// [url]link[/url] shows 'link' as plain text with a dummy image.
// The following line is the original line that processed [url]:
// $bbcode_tpl['url'] = '<span class="bblink"><a href="{URL}" rel="external">{DESCRIPTION}</a></span>';
// ********************************************************************
// See this thread on the Coppermine forum for more information:
// http://forum.coppermine-gallery.net/index.php/topic,58309.0.html
// Please read this thread carefully before deciding to process [url].
// ********************************************************************
$url_removed = '{URL}'; // put the image URL in the tooltip/mouse-over
$bbcode_tpl['url'] = '{DESCRIPTION}<img src="images/descending.gif" alt="" title="' . $url_removed . '" />';
}
$bbcode_tpl['email'] = '<span class="bblink"><a href="mailto:{EMAIL}">{EMAIL}</a></span>';
$bbcode_tpl['url1'] = str_replace('{URL}', '\\1\\2', $bbcode_tpl['url']);
$bbcode_tpl['url1'] = str_replace('{DESCRIPTION}', '\\1\\2', $bbcode_tpl['url1']);
$bbcode_tpl['url2'] = str_replace('{URL}', 'http://\\1', $bbcode_tpl['url']);
$bbcode_tpl['url2'] = str_replace('{DESCRIPTION}', '\\1', $bbcode_tpl['url2']);
$bbcode_tpl['url3'] = str_replace('{URL}', '\\1\\2', $bbcode_tpl['url']);
$bbcode_tpl['url3'] = str_replace('{DESCRIPTION}', '\\3', $bbcode_tpl['url3']);
$bbcode_tpl['url4'] = str_replace('{URL}', 'http://\\1', $bbcode_tpl['url']);
$bbcode_tpl['url4'] = str_replace('{DESCRIPTION}', '\\2', $bbcode_tpl['url4']);
$bbcode_tpl['email'] = str_replace('{EMAIL}', '\\1', $bbcode_tpl['email']);
// [url]xxxx://www.phpbb.com[/url] code..
$patterns[1] = "#\[url\]([a-z]+?://){1}([a-z0-9\-\.,\?!%\*_\#:;~\\&$@\/=\+\(\)]+)\[/url\]#si";
$replacements[1] = $bbcode_tpl['url1'];
// [url]www.phpbb.com[/url] code.. (no xxxx:// prefix).
$patterns[2] = "#\[url\]([a-z0-9\-\.,\?!%\*_\#:;~\\&$@\/=\+\(\)]+)\[/url\]#si";
$replacements[2] = $bbcode_tpl['url2'];
// [url=xxxx://www.phpbb.com]phpBB[/url] code..
$patterns[3] = "#\[url=([a-z]+?://){1}([a-z0-9\-\.,\?!%\*_\#:;~\\&$@\/=\+\(\)]+)\](.*?)\[/url\]#si";
$replacements[3] = $bbcode_tpl['url3'];
// [url=www.phpbb.com]phpBB[/url] code.. (no xxxx:// prefix).
$patterns[4] = "#\[url=([a-z0-9\-\.,\?!%\*_\#:;~\\&$@\/=\+\(\)]+)\](.*?)\[/url\]#si";
$replacements[4] = $bbcode_tpl['url4'];
// [email]user@domain.tld[/email] code..
$patterns[5] = "#\[email\]([a-z0-9\-_.]+?@[\w\-]+\.([\w\-\.]+\.)?[\w]+)\[/email\]#si";
$replacements[5] = $bbcode_tpl['email'];
// [img]xxxx://www.phpbb.com[/img] code..
if (!GALLERY_ADMIN_MODE) {
$bbcode_tpl['img'] = '<img src="{URL}" alt="" />';
} else {
// **** WARNING *******************************************************
// The [img] tag can be used for a serious attack against your website.
// So [img] tags are no longer processed to show the specified images.
// This simple action here is not an ideal solution but is necessary.
// Now [img] tags will show a dummy image instead as a placeholder.
// ********************************************************************
// The following line is the original line that processed [img]:
// $bbcode_tpl['img'] = '<img src="{URL}" alt="" />';
// ********************************************************************
// See this thread on the Coppermine forum for more information:
// http://forum.coppermine-gallery.net/index.php/topic,58309.0.html
// Please read this thread carefully before deciding to process [img].
// ********************************************************************
$img_removed = '{URL}'; // put the image URL in the tooltip/mouse-over
$bbcode_tpl['img'] = '<img src="images/thumbnails.gif" alt="" title="' . $img_removed . '" />';
}
$bbcode_tpl['img'] = str_replace('{URL}', '\\1\\2', $bbcode_tpl['img']);
$patterns[6] = "#\[img\]([a-z]+?://){1}([a-z0-9\-\.,\?!%\*_\#:;~\\&$@\/=\+\(\)]+)\[/img\]#si";
$replacements[6] = $bbcode_tpl['img'];
}
$text = preg_replace($patterns, $replacements, $text);
return $text;
}
It doesn't fix the vulnerability but is a work-around. The tags can be used but the output only isn't displayed to the admin (in admin mode).
-
The state of the admin mode vs user mode is invalid in this case: after all, it just toggles the visibility of the admin menu, nothing else. Subsequently, the vulnerability exists for admins in user mode as well.
-
I tested the code in my test gallery. If the admin is in user mode, the exploit (from milw0rm) doesn't work anymore. If it's a behavior of my testbed only, you could check against IS_ADMIN instead of GALLERY_ADMIN_MODE?
-
Hm, maybe. But after all, it's a workaround, not an actual fix.
-
Shouldn't it be enough to disable bbcode processing of the tags 'url' and 'img' for admins in admin mode only?
My fix solves the issue properly without any inconvenience about gallery functionality, why accomplish a workaround that at least disables BBCode tags for admins?
-
why accomplish a workaround that at least disables BBCode tags for admins?
Your fix is good for now, but:
using POST would be better than using GET, but this would not completely solve the problem, but only would make it a bit harder to come up with a working exploit.
my fix can address the actual exploits
I'm never dealt with hacking web applications. So I don't know how hard it is to fake a POST request. But as Joachim said: maybe an exploit comes, that uses the security hole using POST instead of GET.
I just want to post another way, how users can get the affected bbcode tags back, too. Because I disable the vulnerable tags for admins, my fix should be more secure, but cuts some features for the admin.
As I said: it's a workaround, not a fix. Sorry for hijacking your thread :-[
-
maybe an exploit comes,
Every fix, including official security updates, is meant to address an actual issue.
When a new exploit rolls in, a new patch gets accomplished, and so on: no fix protects against future exploits, otherwise there wouldn't have been 21 minor releases...
Sorry for hijacking your thread
Don't worry, it's not mine at all ;)
-
This patch is actually a mod: could this topic be moved to mod board?
-
I tried successfully a different approach, which - as far as I tested - ensures protection from mentioned exploits without any inconvenience concerning gallery functionality.
Basically, it relies on switching main form (editForm) in usermgr.php from GET to POST method, and then checking for $_POST instead of $_GET/$_REQUEST in delete.php when change_group or add_group action is triggered. This prevents from any request sent by query string to get executed.
When applying this patch to v. 1.4.21 and newer, you must restore previous version of bb_decode function in include/functions.inc.php, by replacing actual version with the code below:
function bb_decode($text)
{
$text = nl2br($text);
static $bbcode_tpl = array();
static $patterns = array();
static $replacements = array();
// First: If there isn't a "[" and a "]" in the message, don't bother.
if ((strpos($text, "[") === false || strpos($text, "]") === false))
{
return $text;
}
// [b] and [/b] for bolding text.
$text = str_replace("[b]", '<b>', $text);
$text = str_replace("[/b]", '</b>', $text);
// [u] and [/u] for underlining text.
$text = str_replace("[u]", '<u>', $text);
$text = str_replace("[/u]", '</u>', $text);
// [i] and [/i] for italicizing text.
$text = str_replace("[i]", '<i>', $text);
$text = str_replace("[/i]", '</i>', $text);
// colours
$text = preg_replace("/\[color=(\#[0-9A-F]{6}|[a-z]+)\]/", '<span style="color:$1">', $text);
$text = str_replace("[/color]", '</span>', $text);
// [i] and [/i] for italicizing text.
//$text = str_replace("[i:$uid]", $bbcode_tpl['i_open'], $text);
//$text = str_replace("[/i:$uid]", $bbcode_tpl['i_close'], $text);
if (!count($bbcode_tpl)) {
// We do URLs in several different ways..
$bbcode_tpl['url'] = '<span class="bblink"><a href="{URL}" rel="external">{DESCRIPTION}</a></span>';
$bbcode_tpl['email']= '<span class="bblink"><a href="mailto:{EMAIL}">{EMAIL}</a></span>';
$bbcode_tpl['url1'] = str_replace('{URL}', '\\1\\2', $bbcode_tpl['url']);
$bbcode_tpl['url1'] = str_replace('{DESCRIPTION}', '\\1\\2', $bbcode_tpl['url1']);
$bbcode_tpl['url2'] = str_replace('{URL}', 'http://\\1', $bbcode_tpl['url']);
$bbcode_tpl['url2'] = str_replace('{DESCRIPTION}', '\\1', $bbcode_tpl['url2']);
$bbcode_tpl['url3'] = str_replace('{URL}', '\\1\\2', $bbcode_tpl['url']);
$bbcode_tpl['url3'] = str_replace('{DESCRIPTION}', '\\3', $bbcode_tpl['url3']);
$bbcode_tpl['url4'] = str_replace('{URL}', 'http://\\1', $bbcode_tpl['url']);
$bbcode_tpl['url4'] = str_replace('{DESCRIPTION}', '\\2', $bbcode_tpl['url4']);
$bbcode_tpl['email'] = str_replace('{EMAIL}', '\\1', $bbcode_tpl['email']);
// [url]xxxx://www.phpbb.com[/url] code..
$patterns[1] = "#\[url\]([a-z]+?://){1}([a-z0-9\-\.,\?!%\*_\#:;~\\&$@\/=\+\(\)]+)\[/url\]#si";
$replacements[1] = $bbcode_tpl['url1'];
// [url]www.phpbb.com[/url] code.. (no xxxx:// prefix).
$patterns[2] = "#\[url\]([a-z0-9\-\.,\?!%\*_\#:;~\\&$@\/=\+\(\)]+)\[/url\]#si";
$replacements[2] = $bbcode_tpl['url2'];
// [url=xxxx://www.phpbb.com]phpBB[/url] code..
$patterns[3] = "#\[url=([a-z]+?://){1}([a-z0-9\-\.,\?!%\*_\#:;~\\&$@\/=\+\(\)]+)\](.*?)\[/url\]#si";
$replacements[3] = $bbcode_tpl['url3'];
// [url=www.phpbb.com]phpBB[/url] code.. (no xxxx:// prefix).
$patterns[4] = "#\[url=([a-z0-9\-\.,\?!%\*_\#:;~\\&$@\/=\+\(\)]+)\](.*?)\[/url\]#si";
$replacements[4] = $bbcode_tpl['url4'];
// [email]user@domain.tld[/email] code..
$patterns[5] = "#\[email\]([a-z0-9\-_.]+?@[\w\-]+\.([\w\-\.]+\.)?[\w]+)\[/email\]#si";
$replacements[5] = $bbcode_tpl['email'];
// [img]xxxx://www.phpbb.com[/img] code..
$bbcode_tpl['img'] = '<img src="{URL}" alt="" />';
$bbcode_tpl['img'] = str_replace('{URL}', '\\1\\2', $bbcode_tpl['img']);
$patterns[6] = "#\[img\]([a-z]+?://){1}([a-z0-9\-\.,\?!%\*_\#:;~\\&$@\/=\+\(\)]+)\[/img\]#si";
$replacements[6] = $bbcode_tpl['img'];
}
$text = preg_replace($patterns, $replacements, $text);
return $text;
}
Is there in this perspective any security hole or operation fault I didn't notice? Anyway, here is the mod:
OPEN
usermgr.php
FIND
print '<form method="get" action="delete.php" name="editForm">'."\n";
CHANGE TO
print '<form method="post" action="delete.php" name="editForm">'."\n";
OPEN
delete.php
FIND
$user_id = str_replace('u', '', $_GET['id']);
CHANGE TO
$user_id = str_replace('u', '', $_POST['id']);
FIND (line 673)
// set this user's group
BEFORE, ADD
if (isset($_POST['group'])) {
FIND (5 times)
$_REQUEST['group']
CHANGE TO
$_POST['group']
FIND (line 678)
print '</b></td>';
REPLACE WITH
}
print '</td>';
SAVE AND CLOSE ALL FILES
I have edit all files, but it don`t work, because I still see the placeholder image (http://coppermine-gallery.net/demo/cpg14x/images/thumbnails.gif). :(
-
OK, I edit all files new and it works - but: when I want to create a new folder, this message appears:
Parse error: parse error, unexpected T_CASE in /var/www/web168/html/galerie_ordner/delete.php on line 688
-
@ nemesis13,
You should know by now that you need to post a link to your gallery when asking for support.
But looking at an older post of yours show a link: http://resident-evil-virus.de/gallery/index.php
That gallery is extremely out-dated. <!--Coppermine Photo Gallery 1.4.13 (stable)-->
Points to consider before returning
- Running a current release is a requirement for support
- An old version is very vulnerable to hackers
- This mod. refers to Coppermine 1.4.2x - your line numbers and mods could very well be invalid
- "unexpected T_CASE" could result from a simple typing error
-
Above all, if one runs v. 1.4.13, applying this mod is definitely pointless! :D
-
I've modded my installation of coppermine (v.1.4.2) to. But when I want to create a new album within a category it takes longer then normal and then no new album is created!
Is this a know problem? Or what do I have to do edit to correct this. Is it very dangerous to leave the function's within delete.php and usermgr.php as they where?
I'm the only user which can create albums and add pictures to albums. I've got Coppermine integrated with the latest version of Joomla. My site installation can be found at: http://twvhengelo.com/fotoalbum/
-
coppermine (v.1.4.2)
Upgrade to cpg1.4.27 or cpg1.5.8 immediately! Then, start a new thread in the correct board if the problem still exists.
-
This thread has become obsolete, with cpg1.5.x getting release as stable some time ago. Locking.