Antispam functionality is a feature that we cannot yet build into the core (because this would probably lead to bots targeting our functionality specifically), but still everybody needs it.

That's why I thought: why not build a simple antispam plugin system? That would allow people to add anti-spam features by dropping one file into the antispam/ folder. These would then be called automatically at certain important points, such as during registration or when making posts.

Anti-spam mods would then be super easy to install: often simply by copying a file into a directory. (I've heard about forum admins that don't want to install mods, which I can understand, because they make upgrading a pain.)

Due to the urgency of fighting against spam, I deemed this important enough to include in 1.5.x.

What we need to decide on is where to include the hooks for antispam plugins. After looking at some of the anti-spam mods out there, I'm currently planning on the following:

• register.php and post.php:
  • before the header is included (so that $required_fields can be populated)
  • at the end of the form (so that other form fields can be inserted)
  • during validation (so that the submitted values can be checked)

Others? Probably viewtopic.php (quick post)...

See https://fluxbb.org/development/core/tickets/936/

Add a 'g_mod_promote_users' options to groups, allowing Moderators to manually promote Users pending Auto-Promote.

X-Frame-Options does not have a whitelist "allow" setting. https://developer.mozilla.org/en-US/docs/Web/HTTP/X-Frame-Options

This change allows me to define FORUM_FRAME_OPTIONS as false so I can disable this header.

Problem

Flux sets the X-Frame-Options: deny header by default. The FORUM_FRAME_OPTIONS constant enables the user to override the default value of deny with another valid value. Unfortunately, the allow-from value does not work in Chrome, preventing the forum to be embedded at all.

Solution

Allow the user to disable the X-Frame-Options header all together.

Proposal

My solution checks:

1. if FORUM_FRAME_OPTIONS is truthy (a string) in which case it will set the header to its value (unchanged behavior)
2. else the header will not be set (new)
3. if FORUM_FRAME_OPTIONS is not defined, the default remains to output the deny header. (unchanged behavior)

# config.php

define('FORUM_FRAME_OPTIONS', 'sameorigin'); // X-Frame-Options: sameorigin
define('FORUM_FRAME_OPTIONS', false); // no X-Frame-Options header is set

This is mainly to allow running a headless install, but it also makes the code a bit tidier and easier to work with.

It's a long time since I've done anything with FluxBB. Does this seem sane? Does it break anything that I've forgotten about?

Ticket: http://fluxbb.org/development/core/tickets/168/

Things that need review:

• These are pretty big and complex features, I might have missed something.
• The JavaScript code
• Should I add code to auto-focus some fields in the new forms I created?
• Somebody glossing over language strings (especially the keys) and form field names (and IDs etc.) would be cool, too.

I think I have tested everything, but there are always situations...

This commit adds cache support to extern.php. TTL can be set in the admin panel - default is not to cache.

Ticket: 267

If someone could review this that would be great.

Caveats:

• password_hash requires >=PHP5.5
• pun_password_hash will fallback to pun_hash if password_hash is not available

This change fixes the long-standing bug https://fluxbb.org/development/core/tickets/1069/ There is a library which implements password_hash and password_verify for <PHP5.5, but I did not include this function in this change.

This change is running live on https://bbs.archlinux32.org/.

PHP installs. This causes search ID collisions. mt_rand is probably overkill for randomizing search IDs. Plain old rand seems to work fine, and is being seeded correctly.

Please go through it to check if this is correct or if I missed out on some stuff. Obviously, as long as the actual minimum requirement is in discussion, this shouldn't be merged yet (unless you agree for this). :)

With the way it currently is, I've successfully crafted XSRF links that can force anyone to post an arbitrary post on any forum, and can force non-admods to do a ton of things, specifically:

• Modify any aspect of their profile such as timezone, signature, and even email if secure email updating is not enabled.
• Post arbitrary posts anywhere on the forum.
• Edit any post they've made.
• Submit bogus reports.

It is also possible to carry out an XSRF attack using only XMLHttpRequest objects, so a potentially malicious site could do an attack completely unnoticed. One could even spam posts on a timer in order to post as many as possible without tripping the flood limiter.

These are some pretty serious issues and I'm surprised they made it this far. All I've done is made confirm_referrer() throw a bad HTTP_REFERER error if the valid script name is an empty string, and the host is different from the forum's base url. I then inserted confirm_referrer(''); wherever one was lacking. The reason why I didn't just do confirm_referrer('scriptname') is because some things (such as posting) are accessible from multiple scripts, so my approach is very flexible. However, it would be vulnerable if there's an unsafe redirect somewhere in the code, though there doesn't appear to be one currently.

This is Garciat from the forums. I made this small modification and tested it; looks like it's working. You guys should review it and see if it works for you. I have very little experience with Git, so let me know if there's anything Git-related that I did wrong.

This changes static time offsets to timezone names (eg "Europe/Paris").

This removes the DST option, as it is now handled automatically by PHP.

Writing in LTR based forums is always a headache for people who use RTL languages. To add LTR/RTL support, we need to use auto direction (dir="auto") to tags which can potentially include either of RTL or LTR text.

My commits handled this in two steps:

1. add dir="auto" to relevant tags in parser.php file
2. remove unnecessary text-align: left from styles` css.

Just notice that I have not been able to text the changes since I faced with difficulties for running FluxBB locally. But I don't think there would be any issue.

In order to verify changes, copy some RTL text in a post. You should see the paragraph starts with RTL character should go to the right and becomes RTL and paragraph (or heading or quotation) starting with English letters should remain as normal.