https://bugzilla.wikimedia.org/show_bug.cgi?id=19646
Jack D. Pond <[email protected]> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |[email protected] --- Comment #4 from Jack D. Pond <[email protected]> 2009-07-12 03:19:31 UTC --- (In reply to comment #3) > Couple quick notes: > First, the first parameter to wfForbidden() seems to always be the "access > forbidden" message; it's probably cleaner to just call that from the function. > :) There are two parts to the HTML 403 message, the header and the body. * msg1 is header * msg2 is body Would be glad to change, but many gov sites have a standard header text such as: * We're big bad mothers so don't mess with us Followed by standard body text * The knock you're hearing on the door is our black suited, dark eyeglass goon squad who are going to take you to a dark place and do terrible things to you. I'd be glad to reduce the customization, but thought, what the heck. > The debug log messages shouldn't be localized; those are internal messages > which should be consistently readable by site administrators in a multilingual > environment so they can debug issues. When I updated the messaging, I thought, hey, some people may want to give out more detailed messages than "you can't get here", so I added that capability with the localization. As long as that message was being sent to the user, thought it might make sense to send the exact same message to the log file. > With $wgImgAuthDetails on, input filenames are being passed into HTML error > messages without validation or escaping; this is a script injection vuln. > wfMsgHTML() escapes the text of the message, then replaces in your parameters > -- the expectation being that your parameters are formatted HTML such as > links. Good point about the script vunerability. Don't know how I missed that one. Unless you have a better approach, I think I'll just take out the "$1" capability in all the messages. Should I be using straight wfMsg instead of wfMsgHTML too? Other suggestions (or someone who might help without bothering you?) > Also we'd generally want config vars like this defined in DefaultSettings.php > so they can be consistently located. I think that img_auth.php isn't used in the majority of MediaWiki installations. Adding that parameter to the generic is something that would only be used if img_auth (rewriting) is used. If you think it's better there, I'm all for it. This way, only used when needed. > I'm a little vague on what the hook accomplishes; if meant for alternate file > repository types, it'll fail as we've already dropped out a 403 result due to > the file not existing in $wgUploadDirectory... It looks like the only thing it > could do is reject access to local files which would otherwise have been > allowed. > Probably if alternate source backends are desired here (say, database storage > or a WebDAV storage backend), they'd need their own implementation on the > repository class for checking path validity and doing the output streaming. You saw straight through me on this one. Yes, I was intending to use it on NSFileRepo, which does namespace validation. That implementation, based on Tim Starling's recommendation, is an extension and alternate "backend" source - and yes, I used a new repository class to do it. With this hook, would be able to use this extension and possibly future acess rejections without branching img_auth.php. See http://www.mediawiki.org/wiki/Extension:NSFileRepo -- Configure bugmail: https://bugzilla.wikimedia.org/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the assignee for the bug. You are on the CC list for the bug. _______________________________________________ Wikibugs-l mailing list [email protected] https://lists.wikimedia.org/mailman/listinfo/wikibugs-l
