Extended Signature Limits

Extended Signature Limits

Description
This Hack allows you to control

• Maximum Number of Lines
• Maximum Font Size
• Links to external Websites
• BBCodes
• Images (max. Number/Width/Height/Filesize)

used in Signatures.

Details
1 Product XML with 2 Plugins, 1 Setting and 17 Phrases

History
1.0.0
Initial Version

1.0.1
Replaced most Settings with Usergroup Permissions
Added Checks for Images (max. Number/Width/Height/Filesize)

1.0.2
Added information Text about applied Restrictions to "Posting Rules"

1.0.3
Fixed a problem with single/double quotes in [size] Tags that allowed bypassing the fontsize limit.

Important: vBulletin 3.5.1
If you are using vBulletin 3.5.1 and downloaded the ZIP of this Hack before 02.11.2005 21:00 CET, please use the attached bitfield XML file.

[Andreas]

Such a phrase is not being used by this Hack.

[gonkowonko]

done now had a duplicate phrase called the same thing

[monktbd]

Checking the image size for attachment from the 3.5.2 still doesn't work on the beta site.
see also :
this post and this.


getimagesize() fails for attachments.
It doesn't return anything (or more specific it won't pass the ($imginfo = getimagesize($sig) ) if condition.
It doesn't fail for attachments of the live site though (used on the beta site).
parsing of the URLs is fine, so $sig contains the correct URL for the images/attachments.

Both sites are on the same server, on different subdomains.
Has anyone any clues whether this can be a vbulletin issue (wrong settings somewhere) or a server setup problem?

[EasyTarget]

sounds like you're in my boat, your host turns off the allow_url_fopen function for security reasons and supports cURL instead.

vBulletin has said they plan on integrating cURL in the future and Andreas has said this issue doesn't effect him so he doesn't plan on supporting cURL.

Here's a message about it from my webhost. (dreamhost)

If you are currently using this (allow_url_fopen) functionality in your PHP code, there is a more powerful and flexible option available. PHP provides excellent support for curl library and its associated functions.

One of our own users has written a short article describing how it is
used and that can be found
here:
http://blog.unitedheroes.net/archives/p/1630/

The official PHP documentation for it is here:
http://us2.php.net/manual/en/ref.curl.php

This change will significantly improve the security of PHP-based applications running on our servers

[mkdevo]

so does this not work with existing sigs, only when modifying?

[Andreas]

This change will significantly improve the security of PHP-based applications running on our servers

That's nonsense
Future PHP versions will not support the current behaviour of allow_url_fopen due to its misunderstanding by most webhosts.

[EasyTarget]

well the blog provided some good examples of how its a security risk, add how cURL has some better functions.

here's the last post

You?re quite right that (used properly) fopen isn?t a security risk. It simply takes data and puts controls on it to allow you to perform various stream related functions, no execution required.

Where it gets complicated is not with the individual fopen call, but the method that PHP uses to implement that function. Internally PHP has some very clever routines that treat any data stream the same way. The problem is that in order to do this, all streams have to behave in the same way. This means that any stream based function has to behave according to that model.

Where this gets really ugly is the fact that internally, the operations to read a data stream for include() are fundementally the same as the operations for reading a data stream for fopen(). One is benign, the other decidedly not.

The simplest, fastest, and most effective fix is to disallow URLs from behaving like streams. While this does inconvenience clueful people who wish to use fopen() functions for urls, it also means that Joe Notanerd won?t accidentally become a proxy for a cross site scripting attack because he never secured his fpassthru() calls.

The curl functions are there pretty much to isolate the web stream functions from normal file operations, plus, they?ve got a number of features that make them more appealing than standard file operations, and that?s to be expected. The mediums are not the same.

[monktbd]

Originally Posted by EasyTarget

sounds like you're in my boat, your host turns off the allow_url_fopen function for security reasons and supports cURL instead.

vBulletin has said they plan on integrating cURL in the future and Andreas has said this issue doesn't effect him so he doesn't plan on supporting cURL.

Here's a message about it from my webhost. (dreamhost)

Thanks but that is not the problem.

allow_url_fopen is turned on, since it works with checking attachments from a VB 3.0.x install (=the current live site) but not for checking attachments for the 3.5.2 install where the sig image limiter is running on (= the current beta site).
Both installs use the same server on different subdomains.
Unless there is a switch/option somewhere in Apache/PHP/MySql that I missed both sites run on the same configuration.

[dvn]

I'm running 3.5.0 and am having trouble with people who were outside the limits *before* the hack was installed. in which case they aren't able to edit their signatures in such a way to be within the limits. my font limit is 14, they've got 16 in their sig, they aren't allowed to change the font size, instead getting a message 'your font is too large'.

is the hack incompatible with 3.5.0?

[PennylessZ28]

bitfield.xml dont' work