an installer isn't needed..
thats a totally different thread (put it in modification requests)

this thread is about security, i think we should stick to the topic.
would the advanced coders be willing to help do security tests on the mods as they're released? or maybe create a new group that'll beta test/security check new mods?

within a few years if this isn't contained now, the board will be one security issue after another, if jelsoft are reading this, i believe it is in your best interests to tackle this problem head on and without hesitiation!

my 2 cents

all this won't happens if jelsoft take in considiration users needs and requests!! limiting the new release to the minimum is not not a solution either..for this we users need those hacks to fit our needs..even if they are full of bugs and security holes!! somehow we do not have choice either..way to go jelsoft!!!

Well according to Scott in a recent post at vB.com it'll be impossible to input malicious user input in future vB versions, so fear not :)

thats never the case, what about basic get functions that can be made to act differently, i can always post different variables.

You can use globalize with this:

STR_NOHTML

Those 2 functions you posted are built-in as part of the intrinsic vB globalize function.

Nice summary of the things globalize can do. :)

Add-on authors should utilize the built-in security vBulletin offers a lot more, rather than writing their own security checks.

Yeah I just went over every file in my new RPG version that didn't have globalize() already, and used it.

A side note about globalize():
If you want to run globalize() on an array, you have to skip using the "=>" stuff.
It would then be smart to run the functions quoted above on the variables as they are submitted into $DB_site->query() :)


You sayin that by using the htmlspecialchars_uni(trim()) there's no need for addslashes()?

Where are they all documented then ?

i'd like to know as well, i've done some searches but wound up empty

At this time the API isn't documented. It will be documented for the next release, however the usage of the inherent security features of vBulletin will change significantly so most hacks will need to be reworked anyway. We plan on providing full API documentation when the system is in a state to document.

As it is now, you need to go through the include folder and review the functions there to see what they do. Not optimal but that is what there is. Before the 3.0 release we concentrated on the Admin Control Panel Documentation because it would serve the most customers. When it came time to document the API enough significant changes were proposed and/or implemented that it was decided to postpone it.