Only way to do that would be to provide an .htaccess for the local directory to be included with the WoWRoster packaging.

I found all this information through searches in google and such. I asked my friend (who's a web developer) about a way for you all to add it into the roster, and he said that's the only way (what I stated above).

I think Zanix is looking more for --- what is config.php doing that would cause mod_security to block it?

Eurynome wrote:I think Zanix is looking more for --- what is config.php doing that would cause mod_security to block it?

Yes

No luck so far with me, of course it config.php never did work for me.

The other problem is I did hand change some of the values in the database to see if I could bypass config.php completely. I only changed the banker data in the config table. The changes were ignored, though, as the roster still looks for the default 'BankMule' in the player notes.

I get the 406 error and that concerns me, but the config table in the database being ignored concerns me more. I also am stumped about it.

corexian wrote:No luck so far with me, of course it config.php never did work for me.

The other problem is I did hand change some of the values in the database to see if I could bypass config.php completely. I only changed the banker data in the config table. The changes were ignored, though, as the roster still looks for the default 'BankMule' in the player notes.

I get the 406 error and that concerns me, but the config table in the database being ignored concerns me more. I also am stumped about it.

I put the code Jhaeldril posted in the .htaccess in my public_html (root web folder) and it took care of the 406 error for me.

Well, I know some servers take time to recognize changes to the .htaccess file or update to new ones so I'll give it some time, but so far it hasn't made any difference at all.

config.php still shows up when I login but upon submission of changes, it throws the 406.

Note: I figure I should specify about what I've tried changing in the database. For id 9010 and 9020 in the config table of the database I changed the config_value to 0, BANKER respectively. I wanted to see if the system would go straight to the data without the immediate need for config.php to work.

The guildbank still performs in exactly the same way as it did before changing values, though. This made me think that the default values could still be pulled from another location should the db query fail for some reason. I've been over much of the code and cannot find where this would happen if it does. But it appears as though the config table gets completely ignored.

admin/config.php is only an interface to the table "roster_config"
No other part of roster includes or uses admin/config.php

corexian, are you sure you are actually saving the chages to those rows?

I was having an issue where I could upload my characterprofile.lua file straight from the update page on roster, but I couldn't from uniuploader. I also coundn't sync my Uniadmin settings.

I removd the filter of anything config.php and just used:

SecFilterEngine Off


in my .htaccess file and VIOLA magic. You sir are a life saver.

I've been trying to learn how mod_security works - but there's not a lot of forwardly visible information available.

Some of the text on the front page scares me tho;

From http://www.modsecurity.org

ModSecurityTM is an open source intrusion detection and prevention engine for web applications (or a web application firewall). Operating as an Apache Web server module or standalone, the purpose of ModSecurity is to increase web application security, protecting web applications from known and unknown attacks.

O_o I love it when software determines things for me. "We're not letting this happen because it might be bad."</sarcasm>

Oh, wow, this wasn't too hard.

In ModSecurity they apparently filter certain things from PHP;
http://www.modsecurity.org/download/rul ... y-php.conf

They say these rules are only a basis/suggestion (I'm assuming that it's just a C.Y.A. in case their software misses an exploit somehow)

Zanix - do you see anything in their filters that may be triggering for admin.php?

Here is a link to all of their 'suggested' rules; http://www.modsecurity.org/projects/rules/index.html

I find this quote interesting;

Note: These rules were designed to work in detection mode. Although it is possible to use the rules in prevention (block) mode, this works well only certain types of web applications. Content management applications and forums, in particular, are expected to produce a higher number of false positives. Use prevention mode at your own risk, and only after you've completed a test run in detection mode.

I guess our host providers missed that part - that it should be used in detection mode unless you know nothing will break.

@ zanix

Yeah, the values definitely saved when I changed em through phpMyAdmin. And a day later, after the .htaccess changes, the behavior is still the same.

In regards to config.php being the only script using the config table, I might be wrong but it looked to me that the config table does get used to some degree in a few of the other scripts. For example, the guildbank script needs to know what conditions to search for in the database query. NOTE: Upon reflection, I realize you weren't saying this. Please disregard this I misread.

Since the bank feature is the most important thing that we've not been able to work out, I thought about backing up the old guildbank script and hand-editing the query in a copy to look for the conditions our guild uses. I've been busy with building an application for work, though, so not enough time just yet.

But as many before have said, you guys are doing a great job. The roster looks the best it ever has and it's a great way for a guild to visualize itself and what they are capable.

@ Eurynome
I can't readily see anything...

@ anyone
Can anyone do me a favor?
Ask your web hosts if they have mod_security logs?
And see if you can get snipits of where roster is concerned

If they question it, say that we want to make roster work with it

Let me throw my hat in the "I can update via the website but not UniLoader" ring.

I've read the entire thread and have modified the .htaccess file and double checked it several times just to make sure I didn't fat-finger it.

I still however am getting the (406) Not Permissable error message.

I went digging for the mod_security on our host but the CPanel configuration front-end doesn't seem to provide access to modifying any such configuration.

I blindly CHMOD the config.php and update.php to 777 from 644 but the results were the same.

Have there been any new troubleshooting suggestions floating around since the last post?

This web-app puts a good face on any guild that's out there. I can't begin to describe how impressive this code is. Keep up the great work.

Cheers