Show Posts

This section allows you to view all posts made by this member. Note that you can only see posts made in areas you currently have access to.

Messages - CerealGuy
31
Bug reports / [Security] Re: BBCode in SQL Database
« on February 9th, 01:06 PM »
Quote from Nao on February 9th, 11:26 AM
Quote from CerealGuy on February 7th, 11:58 AM
Yup, totally aggree with your points. On the other hand, adding bbcodes via plugins is quite a handy thing. So i won't say the idea is bad, just the way it's done in the moment is not the best.
Maybe do... BOTH?!
- Have the main BBCode in a source file,
- Give plugins the ability to add or replace BBCode,
- Only, plugins can't add code in the database, rather a function name. IIRC plugin files are always loaded so it's easy enough to just put the code in a plugin file and it should get executed.

Or, if it's too much to handle, just do points 2 and 3, because it still means putting the code to be executed into a source file, goddammit.
Yeah, that's probably the most realistic solution..?!
- First thing I want to do is moving all "validate_funcs" to
  Subs-BBC (nearly done with that).
- Next thing is refactoring those functions, making more
  clear what they do (figured out that the do nothing which
  you should describe with the term "validate", most of them
  trim or beautify the content.) and  understanding why the
  hell there are often the same tag twice with nearly the same
  "validate_func". I'm sure it would be enough to have one of
  those function for each tag (which needs this stuff).
https://github.com/C3realGuy/wedge/commit/791bdfa2632190b0c23f570e4bc581de9a7bc2bd#diff-ea931b81508cfb000ca2c54e529ff570R1520
- If this is done I want to look if it's possible to "hardcode" all those
  default bbc tags in a nice function. Something like loadBBCodes(),
  which returns all default bbc tags plus loads all others from sql.
  Have to see how the disable tag stuff is done. Want to add a
  hook here too, so plugins really have all the power over bbcodes
  without the need of modifying the bbc parse code or doing some
  regex stuff on top of it.

It's a bit to do, won't get bored the next days. The Problem is not
the coding, it's understanding what goes on in Subs-BBC :lol:
Quote from Nao on February 9th, 11:26 AM
Well, I've moved Wedge.org and Noisen.com at the same time. Wedge.org was flawless, but Noisen.com is running a heavily customized SMF 2.0 RC, with none of the code fixes to make it run on PHP 7. However, that server can ONLY run one version of PHP (because the admin doesn't want to bother, and it's okay), so I had to manually convert SMF code to PHP 7 *and* my custom code as well, of course... Took at least a day.
If I move my site again, I'll make sure it has PHP 5 as an option. I'd rather use PHP 5 for Noisen, even though it's now working correctly in PHP 7.
Sorry if it was confusing. Wedge was fine.
I'm having Wedge problems with my other new site though, ahah. But again-- server problem. Another server, other problems: this time it's file permissions. The difference is, the admin has been AWOL for 2 months now. Not great...
Didn't play with a pure webspace in years, and i know why :D You just have more control, more power and of course more responsibility. But stuff like let's encrypt (free ssl certificates in case you don't know them), full control about software which is running and the configuration will always let me choose an vps/kvm/whatever over a webspace.
Quote from Nao on February 9th, 11:26 AM
Quote
PS: It feels good to see wedge back under active developement:D
Yeah, me too. And thank you for being the only developer who still believes in it.:)

Although I never felt back about leaving it -- I just considered it finished. What I'm doing is maintenance work, plus extra minor features from time to time because, well, it's fun?
My game development plans were set aside due to the state of the market. Purely from a business point of view, there just isn't enough visibility for a new game, and for now I don't want to rely on my 'Kyodai' brand name to attain more recognition. So I just focus on selling that old game and building that game trading site. (Which for now is just a game trade matching site. Supposed to be unveiled today, except the site isn't working due to aforementioned permissions ahah.)
Wedge is quite finished. It's totally usable, I only tweak stuff which I don't like how it behaves. For example the WYSIWG Editor. It's fully working, but awful :D Will be the next thing i want to look at. And some features I see around other forum softwares which i like. For example mark quotes. So you mark a part of post and you can only quote this part. Really like this idea, have to see how i can implement that. Maybe stuff for a plugin.

Besides that, i said it already in parts here and there, wedge is in my opinion the only good forum software around.
It's nearly perfect with balancing out pure html/css functions and extra js. It has many js stuff which makes it feel modern and dynamic without making it unusable on browsers without js. I mean solutions like nodebb they won't work in a browser without js. Those "in browser apps" are cool for sure, but not for a forum software (in my opinion). They are slow, make problems with search engines, are unusable with noscript. But forums should be accessable by as many people as possible and shouldn't make problems.
The next thing is mobile/responsive design. A lot of forum softwares aren't able to this. Xenforo just looks really really bad on a smartphone. They didn't understand this *less thing which wedge does. Less padding and style elements is more on a mobile screen. You wan't to use as much of the screen as possible to show content without confusing the user. Xenforo also didn't do this js thing well. It's just bloated with js even if it's more of traditional "non ajax" solution compared to nodebb. I hate it to surf on any xenforo forum. Only thing which is maybe worse is an old vbulletin forum. I just always fear to lose my account's email and password to some hackers :D
Wedge feels lightweight, it loads super fast on the browser. It looks modern, has a special touch to it which you will recognize. And it has a lot of really good ideas implemented. Besides that, it's super stable. I think we use wedge on our forum since 3 years. Never had a serious problem with the forum software. Not even a small one.

But still there are problems with wedge.
- PHP is just not modern anymore. In fact, it's a bit dying.
  I'm not sure about that, but for example websockets aren't
  supported yet in php. Which could be a nice thing to have,
  also for wedge. Especially for notifications. Wedge is maybe
  the last and best php Forum Software.
- Besides the PHP thing, the codebase is old and unmaintained.
  No unit tests, no coding style standards. You also don't want to
  touch that code, risks are too high to break a thing and don't even
  notice it. Not a big of a problem, there aren't too many who use wedge
  anyway :D 
- No documentation, no helper/"framework like" functions to make life
  easier for plugin developers. As a plugin developer you write so many
  functions again, which are maybe already implemented in the wedge
  core and you just could reuse. But you don't know of them and never will.
- In general you can make wedge do everything you want, but it's often not
  a nice way. It's more like forging it with a flamethrower.
- Some standard functions are just not as good as they should. For example
  the editor. Color chaning is bad, you can't asign a choosen color to another
  marked text without first changing it's color to something else and than to
  the color you want. Makes no fun.
  Or Private Messages. It's this old private messaging system you know from
  Bulletin Boards. It's just old and feels bad to use. It's a bit like emails and this
  is already bad. In fact i would always prefer to write you a message on any
  instant messanger instead of using wedge.

Wow this is more of an essay and totally off topic. But who cares.
32
Archived fixes / [CSS] Re: Login looking bad on small screens
« on February 9th, 12:57 PM »
Looks fine on all my devices. The only thing to tweak is when it should change. 600px seems to be a bit high in my opinion, alread on 550px it looks ways better. But this is something we can always change.
33
Archived fixes / [CSS] Re: Login looking bad on small screens
« on February 9th, 11:14 AM »
Looks fine on my galaxy s3, will try later on other devices :cool:
34
Bug reports / [Security] Re: BBCode in SQL Database
« on February 7th, 11:58 AM »
Yup, totally aggree with your points. On the other hand, adding bbcodes via plugins is quite a handy thing. So i won't say the idea is bad, just the way it's done in the moment is not the best. Also this validate thing i really don't like. The name suspects a very limited function, even if it's not. Have to think of something for this.
I will give it a try and see what i can do. I'm ill in the moment (EB Virus is quite a nasty one) so I have some time.

OT:
Quote from Nao on February 7th, 12:58 AM
PS: I just have no time to look into this right now. I'm pretty busy with the new site. Plus I may be moving servers again in the future-- this one is so blazing fast, I love it, but there are so many configuration issues, it gives me nightmares... -_-
What kind of a server are you using that the configuration issues give you nightmares :hmm:

PS: It feels good to see wedge back under active developement :D
35
Bug reports / [Security] Re: BBCode in SQL Database
« on February 6th, 11:23 PM »
Bumping this, because this one bugs me a bit. I think this a security problem, even if it's low priority.
Why? Because if someone hijacked a database where a wedge instance is running on, he doesn't need too much more
to also undertake the php execution level. Which basically means he has many more possibilities to harm you.
Injecting some bad code into a often used bbcode validation, maybe changing the type of it and accessing a post where this bbcode gets translated into html (and bad code) is all what needs to be done.

It wouldn't be hard to make this ways less evil. We just need to get rid of those php code in the database and load it from a file. So adding three fields: validation_plugin, validation_file, validation_func would be all we need besides some code moving and a bit of adjusting.
Just to mention it again, php code in a database is not even handy. If there's an exception you won't know on which bbcode (in the moment), to debug it you have to update your database, to fix it you need to roll out a database update. This just makes no real sense in my opinion. And if you want to hook in with a plugin, you have to do hacky stuff (see my hidemod post on this topic).

36
Quote from Nao on January 30th, 02:27 PM
Hmmmmm... That might actually explain it! I was thinking of exclusive locks but couldn't figure out why this would only happen with ViewRemote.
I'll give it a look.

:edit: I don't know... The first thing that gets called is copy(). Meaning the file SHOULD exist, in its entirety, by the time a second AJAX request is triggered. Of course it could still be unsuccessfully copied or something.
I don't know how copy() is exactly working. It's possible that the function first creates the file and then streams to it. Would make sense because you can use copy with network resources. So maybe it would already be an improvement if apply_plugin_mods does it manually. I think the file gets written on the fclose call to the disk, but i'm not sure about that.
Another option would be to set LOCK_EX with flock() until the file is completely written and minified, and then test on other requests if it can safely be acccessed with LOCK_SH. However, i don't know if those fopen + flock calls are imperformant? Also it's not possible to pass an file resource to require_once()..
Problem is, that it's a pain in the ass to test this thing. Don't know how to provocate this race condition.
If we are able to create a test for this, it shouldn't be too hard to fix.
37
I can reproduce it if gz/app/ViewRemote.php is an empty file. Maybe this happens if file gets renewed and in the same moment you  try to access it? So file is still empty or something and you try to load the file?

What makes me wonder is that this only happens to ViewRemote. Never saw a similiar error with any other required files...

EDIT: I have a theory:
When we go to admin panel, we fire two ajax requests against ?action=viewremote
?action=viewremote;filename=current-version.js and
?action=viewremote;filename=latest-news.js

If ViewRemote isn't cached, wedge will try to create it very likely on the current-version.js request. But in the same time we will ask again for viewremote, maybe the file is already created, but not completed. So the first thread (current-version.js) is creating the file, but not finished. In the same time the second thread (latest-news.js) is trying to loadSource('ViewRemote'), loadSource checks if file exists (it exists) and then requires it. But it's empty or not done yet. So second thread will result in an error. So this could be kind of a race condition.
38
Plugins / [Plugin] Re: HideMod
« on January 22nd, 12:05 PM »
Quote from CerealGuy on February 8th, 2014, 02:36 PM
Im using the display_post_done hook to replace the hide(-reply) stuff and check if user is allowed to do so. But perhaps the bbcode stuff in plugin-info.xml is bether?
Quite an old one, but I finally found a solution for this and wanna share it with you.
The Problem with my first approach was that i used regexes to figure out where my
bbc tags for hide & hide-reply where. So I didn't drop in the normal bbc parsing wedge
does and did it just after everything was already parsed. This is a thing which definetly
can be done, but it has many downsides. For example you have to handle every "special"
cases the wedge bbc parser handles already again. Like bbc tags inside a code tag etc.
And you have to make sure that your regex really works in every case :lol:
All in all it would be better to just inject it somehow in the normal bbc parsing process.
And it's possible, even when you want to do more complex stuff like in this plugin.
The key to glory is the validate-func which allows us to inject php code in the normal bbc
parsing process. Because the most bbc tags only add some html before or after and don't
care about who's viewing this post (we do, because we want to determine if the current user
is allowed to watch the content in the hide tag or not).
I guess the purpose of the validate-func was to validate anything related to the tag in more
complex use cases. Eg. validating complex urls or stuff like that. But we can also modify the
part of the message containing the bbc tag, and that's what we want to do.
All you need to do is adding a php file to your plugin with a function which gets called by the
validate-func eval block. And you need to add the bbcodes to your plugin-info.xml:
Code: [Select]
  <bbcodes>
    <bbcode tag="hide" type="unparsed_content" block-level="no">
      <content>HIDDEN CONTENT: Like to see</content>
      <validate-func>loadPluginSource('CerealGuy:HideModv2', 'src/Hide'); validate_hide_bbc($tag, $data, $disabled);</validate-func>
    </bbcode>
    <bbcode tag="hide-reply" type="unparsed_content" block-level="no">
      <content>HIDDEN CONTENT: Reply to see</content>
      <validate-func>loadPluginSource('CerealGuy:HideModv2', 'src/Hide'); validate_hide_reply_bbc($tag, $data, $disabled);</validate-func>
    </bbcode>
As you see, i call plugin function named "validate_hide_bcc" (or "validate_hide_reply_bbc") with three arguments.
If you catch them in your function header as referenced variables, you are free to modify all values of them. Play around with them, you will understand what's where easily.
Sounds straight forward, but there was still a hurdle to clear. The Problem was that I didn't know of which type my bbc tags have to be. With some types just nothing happend, with some others it got parsed at some times and sometimes not. Don't ask me why, i didn't understand the differences and purposes of those types. Maybe someone knows this stuff @Nao? :whistle:.
Anyways finally i found the right one, "unparsed_content".
This was a small background report about stuff which took me quite some time to figure out. Maybe it helps somebody.

Tl;dr: If you want to do more complex stuff with bbc tags, add them via plugin-info.xml and use the validate-func to inject your own code. Setting the type of your custom bbc tags to "unparsed_content" did work for me best, other types didn't work out that good.
39
The Pub / Re: Wedge&PHP 7
« on January 20th, 08:22 PM »
No idea about the Problem, but fixing the queries sounds better. Does wedge get incompatible to old mysql versions with those new queries?
40
It's not a bug, it's a feature :lol:

Still it looks for me a bit... weird.

Mobile with "fix"


Mobile without


I get what you mean, on mobile the default one looks ways better. How about join together both worlds?

Otherwise this is stuff for custom skins :whistle:

What I don't like about this, is the inconsisty. When the topic names of prev and next are similiar long, it kinda looks like my fix. Some other times it's aligned to top and bottom. It sometimes looks broken. For example on the next topic, it looks a bit like with my fix ^^

PS: This thing bugged me out very early, it's the reason why i disabled this thing completely. The only reason I stumbled across this once again was some bug with topic length. You can't set how long topic names can be in the moment, and it's done a bit weird. Have to dig around this Mange Stuff and add it as a new setting i think. Not the right stuff for a plugin :lol:
41
Archived fixes / [CSS] .postheader and previous/next post title looking bad
« on January 16th, 03:01 PM »
There are some problems with .postheader and the .prevnext_prev/.prevnext_next css clasess.
- .postheader does align the items in center but strecht is better because otherwise items don't
vertically aligned on the same level.
- #top_subject has no fixed weight. Set to 60% (prev's have 20%)
- All the elements should have an word-wrap: break-word.

Fix:
Code: (section.css) [Select]
// Topic title and Quick access
.posthead
width: 100%
padding: 8px
border-radius: 12px
background: rgba(0,0,0, .015)
box-sizing: border-box
@if ie[-7]
div mixes .inline-block
@elseif $can_flex
display: flex
align-items: stretch
> div
flex: 1 1 auto
@else
display: table
> div
display: table-cell
vertical-align: middle
@endif

#top_subject
padding: 4px 8px
font: 100 1.6em/1.2em $head_font
text-align: center
color: gray
letter-spacing: -1px
width: 60%

#top_subject, .prevnext_prev
word-wrap: break-word;

// Previous/next topic links inside .posthead
.prevnext_prev
font: 400 1em/1.3em $main_font
text-align: left
width: 20%
a
color: $reddish

.prevnext_next extends .prevnext_prev
text-align: right

Pictures:
before:

after:


PR: https://github.com/Wedge/wedge/pull/49

EDIT: You can watch this bug right in this topic :lol:
42
Archived fixes / [CSS] Re: Login looking bad on small screens
« on January 16th, 01:23 PM »
Fixable without changing any html.
Code: (section.css) [Select]
@if guest
.login
margin: auto
dl
overflow: none
clear: right !important
dt, dd
margin: 0 0 .4em
width: 44% !important
padding: .1em
dt
float: left
clear: both !important
text-align: right
font-weight: 700
dd
width: 54% !important
float: right
text-align: left
padding-left: 0px !important
clear: none !important
p
text-align: center
input
max-width: 100%

@media (max-width: 450px)
.login
dt, dd
float, text-align: left
width: 100% !important

This stuff caused problems:
Code: (section.css) [Select]
// Even smaller? A smartphone, maybe..?
@media all and (max-width: 600px)
body #wedge // Precedence killjoy.
overflow: hidden

dt, dd
clear: both
width: 100%
dd
padding-left: 12px
On small screens (<= 600px) dt, dd got modified.
 Clear got set to both, width to 100%, padding-left: 12px got added to dd.
Nothing we want on .login dd or .login dt. Therefore added !important flags
that those rules don't get overwritten. Also i removed an overflow, those
added scrollbars look really bad and aren't needed. Everything's on screen.
And input rules for max-width :100% didn't get set for the password input.
Now setting it for all inputs.
Besides that, on very small screens (<= 450px) we now do line breaks
between dt and dd. Looks better.

Small Screen (screen width: 630px)

Very small screen (screen width: 353px)


PR: https://github.com/Wedge/wedge/pull/48
43
Plugins / [Plugin] Advanced Home Topics
« on January 15th, 02:06 PM »
Advanced Home Topics

A plugin for wedge giving you more control over the topics block you can add to you Homepage->Custom Content.
Features:
  - Multiple working `topics` blocks
  - Change title of each `topics` block
  - Limit include boards
  - Limit exclude boards
  - Modify steps in which n increases
 
Can you give me an Example?
Sure, look here:


How to install?

Drop the `advanced-home-topics` folder which you can find in this repository in to your `<wedge_install>/plugins` folder and activate it over your Admin Control Panel.

How to configure?

1. Go to `Admin->Configuration->General Options->Homepage`
2. Modify `Custom Contents`
3. Add something like `topics:1|Some Special Posts|3;4||false|1;2;3;4;5;6;7`
4. Format looks like this `topics:<num posts to show by default>|<custom name, empty for default>|<include these boards, empty for all, divide with ;>|<exclude these boards, empty for none, divide with ;>|<set to true if you want to hide Boards>|<steps in which we shall increase. By default 5;10;20;50;100. Divide with ;>`

Where to find?
https://github.com/C3realGuy/AdvancedHomeTopics
44
Archived fixes / [LOW-SQLi] Possible SQL injection on ssi_recentTopics
« on January 14th, 12:31 PM »
ssi_recentTopics() is not filtering the $num_recent argument correctly.
Code: [Select]
// Find all the posts in distinct topics. Newer ones will have higher IDs.
$request = wesql::query('
SELECT
t.id_topic, b.id_board, b.name AS board_name, b.url
FROM {db_prefix}topics AS t
INNER JOIN {db_prefix}messages AS ml ON (ml.id_msg = t.id_last_msg)
LEFT JOIN {db_prefix}boards AS b ON (b.id_board = t.id_board)
WHERE {query_see_topic}
AND t.id_last_msg >= {int:min_message_id}' . (empty($exclude_boards) ? '' : '
AND b.id_board NOT IN ({array_int:exclude_boards})') . '' . (empty($include_boards) ? '' : '
AND b.id_board IN ({array_int:include_boards})') . '
AND {query_wanna_see_board}' . (empty(we::$user['can_skip_approval']) ? '
AND ml.approved = {int:is_approved}' : '') . '
ORDER BY t.id_last_msg DESC
LIMIT ' . $num_recent,
array(
'include_boards' => empty($include_boards) ? '' : $include_boards,
'exclude_boards' => empty($exclude_boards) ? '' : $exclude_boards,
'min_message_id' => $settings['maxMsgID'] - 35 * $num_recent,
'is_approved' => 1,
)
);

The dangerous part: 'LIMIT ' . $num_recent,'
You can exploit it through custom homepage contents over acp. (Adding something like 'topics:10 UNION SELECT...'). But you need permissions to acp. And even if you have them, the anti hacking protection of wedge looks quite nice. No multiple statemants, it detects weird behaviour couldn't really exploit it besides an more or less useless blind sqli which just worked once :lol:.
But still, better fix it.

How to fix:
Code: [Select]

// Find all the posts in distinct topics. Newer ones will have higher IDs.
$request = wesql::query('
SELECT
t.id_topic, b.id_board, b.name AS board_name, b.url
FROM {db_prefix}topics AS t
INNER JOIN {db_prefix}messages AS ml ON (ml.id_msg = t.id_last_msg)
LEFT JOIN {db_prefix}boards AS b ON (b.id_board = t.id_board)
WHERE {query_see_topic}
AND t.id_last_msg >= {int:min_message_id}' . (empty($exclude_boards) ? '' : '
AND b.id_board NOT IN ({array_int:exclude_boards})') . '' . (empty($include_boards) ? '' : '
AND b.id_board IN ({array_int:include_boards})') . '
AND {query_wanna_see_board}' . (empty(we::$user['can_skip_approval']) ? '
AND ml.approved = {int:is_approved}' : '') . '
ORDER BY t.id_last_msg DESC
LIMIT {int:num_recent}',
array(
'num_recent' => $num_recent,
'include_boards' => empty($include_boards) ? '' : $include_boards,
'exclude_boards' => empty($exclude_boards) ? '' : $exclude_boards,
'min_message_id' => $settings['maxMsgID'] - 35 * $num_recent,
'is_approved' => 1,
)
);

PR: https://github.com/Wedge/wedge/pull/43

Many limit arguments don't get passed parameterized in SSI.php. We should change that.

EDIT1: WTF. This is nearly the same in the SMF codebase. Do I miss something or is this just really bad practice? I mean, i don't know if they have a hacking protection like wedge, but if they don't...
Besides that it looks like they fixed it sometimes and sometimes not :whistle:
https://github.com/SimpleMachines/SMF2.1/blob/release-2.1/SSI.php#L518

EDIT2: Fixed other limits too. https://github.com/Wedge/wedge/pull/44
45
Code: (diff) [Select]
-$txt['mark_read_short'] = 'Ale Themen als gelesen markieren';
 +$txt['mark_read_short'] = 'Alle Themen als gelesen markieren';

https://github.com/Wedge/languages/pull/30