Summary:
So what IS different in this reworked version than the previous one?
Spoiler:
The forum's code has been optomized, so now the forum loads much faster. The forum is more user-friendly, and the style doesn't hurt your eyes anymore, like last time. :ott1:
Membergroups are not that complex anymore, it's just a very simple process that registers your permissions upon visiting the forum. Styling has also been reworked.
The theme now loads with its own preset data, instead of the old "the theme is the forum" concept.
A reworked BBCode parser has also been created-BBCode processing is much more efficient.
The forum and subforum system has also been revised, allowing a much smaller file for creating forums, thus faster execution that. We have applied the same thing towards posting and replying.
Breadcrumbing has also been modified. Now, preset functions are defined to find the objects that are "before" your current state.
Advanced session control now allows users to set an auto logout time, or to not allow the account to be logged in on more than one computer.
So how can I help?
You can help by downloading the source code below.
You can try finding security bugs, such as possible SQL injections, XSS injections, and other possible bugs.
..............................................
What will the Pre-Alpha Public Release Package include?
The Pre-Alpha Public Release Package is designed to be used by PHP, HTML, or Javascript scripters. Please report any bugs, vulnerabilities, or simply anyways to make the code more efficient.
Spoiler:
Categories
Category Viewer
Unlimited Forums
Unlimited Subforums
Forum Viewer
Posting threads
Replying to threads
Stickying threads
Locking threads
Membergroups (only editable through SQL db)
Forum permissions (only editable through SQL db)
Thread (View Forum) Pagination (only editable through data/settings.php)
Reply (View Thread) Pagination (only editable through data/settings.php)
Basic Styling System
Breadcrumbing
-Finished AdminCP
-Maintenance mode
-User Profile Saving (.fpr - Forum PRofile files; basically XML)
-Finished ModeratorCP
-Finished UserCP
-Admin, Moderator, and UserCP Styling
-UserCP Styling permission for membergroups
-Thread rating
-Number of people viewing forum
-Number of people viewing thread
Peek into the "far" future (Beta I)
Spoiler:
-WYSIWYG editor
-Trash forum (for deleted threads; threads can be chosen to completely deleted too)
-"Like/Dislike" threads
Peek into the "far far" future (Beta II)
Spoiler:
-Automatic thread and reply updating system (AJAX)
-Two types of data storage:MySQL and files (when a new forum is created, a folder with the name of the forum is created, and a settings file for that forum is created, containing the ID, threads, etc. When a thread is created, an HTML file is stored in that folder. When replies are made, the thread file is edited) *THIS IS JUST A CONCEPT*
-Thread quick editing (AJAX)
-Quick Replying (AJAX)
-Blogging
So what's next?
Spoiler:
Now that the Alpha has been released, we'd like you to report any bugs or vulnerabilities.
Also, be on the look out for new patches here.
In the Alpha II, automatic patch detecting will be implemented. (You can implement it now in index.php, but it'll just give you a warning since reading files isn't turned on on my web server)
Patches
Spoiler:
SimpleBB.Patch1 - Recommended
Spoiler:
Code:
<?php
/*THIS IS A PATCH FOR SIMPLEBB PUBLIC ALPHA RELEASE PACKAGE. DO NOT RUN THIS PATCH IF YOU ARE NOT USING THAT VERSION.*/
/*
* Place this file in the root directory of your simpleBB installation.
* This file should be in the same folder as the folders themes and data are in.
*/
echo "<b>Patching file (current object:$file): Stage 1 out of 1...";
//Attempt to write to the file
$content = "<?php\r\n/*This code was automatically generated by a simpleBB patcher*/\r\n session_start();\r\nsession_destroy();\r\n?><meta http-equiv='refresh' content='1;url=index.php' />";
fwrite($fo, $content) or die("The patch failed.");
fclose($fo);
echo "Patch succesfully completed!";
echo "Click <a href=\"?act=delete\">here</a> to delete this file";
?>
SimpleBB.Patch2 - Recommended
Spoiler:
Code:
<?php
/*THIS IS A PATCH FOR SIMPLEBB PUBLIC ALPHA RELEASE PACKAGE. DO NOT RUN THIS PATCH IF YOU ARE NOT USING THAT VERSION.*/
/*
* Place this file in the root directory of your simpleBB installation.
* This file should be in the same folder as the folders themes and data are in.
*/
fwrite($fo, $content) or die("The patch failed.");
fclose($fo);
echo "Patch succesfully completed!";
echo "Click <a href=\"?act=delete\">here</a> to delete this file";
?>
17-12-09
PaulBub
Re: SimpleBB - Completely Re-engineered
You should work on a better skin it will give you more credibility.
17-12-09
King Grub
Re: SimpleBB - Completely Re-engineered
Yea looks ugly, but the features seems cool:)
17-12-09
s-p-n
Re: SimpleBB - Completely Re-engineered
The Theme looks similar to my WysGui 0.01 BETA thing I made when I lost connection to the internet for a few weeks time.. To be perfectly honest, I really didn't like that theme afterward.. Some how at the time it seemed like a good idea.
I too have some sort of "designer's block".. I guess some coders are just bad at it, like postNuke, they're design is always so terrible..
Don't feel bad about going out and getting a template to use for your software.. Free or paid for, leave code comments of where you got it, or whatever the terms say to do... You don't need to make everything, just give credits.
Besides, it helps you to learn how to integrate a vast amount of designs from people all around the world. So you'll find times you need to change the way you do some things, and the back-end becomes more versatile, and all that as you go. So in that respect it's a very good thing if you can get a free template and integrate it into your forum. It makes other people think they can integrate their templates, and then you got some people contributing and it gets better, faster.
Take it or leave it, that's my advice.
17-12-09
FrostElite
Re: SimpleBB - Completely Re-engineered
Nice to see that you didn't give up on this
18-12-09
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Post updated, download link and SQL added.
18-12-09
gunnerone
Re: SimpleBB - Completely Re-engineered
Nice work mate keep it up.
18-12-09
Tyler
Re: SimpleBB - Completely Re-engineered
Yeh, sorry.. but the skin lacks.
Overall, looks like a nice project.
I can't really say anything other than that of the skin until a demo or download is available.
18-12-09
Markshall
Re: SimpleBB - Completely Re-engineered
The skin is terrible.
19-12-09
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by Tyler
Yeh, sorry.. but the skin lacks.
Overall, looks like a nice project.
I can't really say anything other than that of the skin until a demo or download is available.
The files have been posted. :)
19-12-09
s-p-n
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by http://localhost/forum.prealpharlspkg/
Fix that.. The tables were created though, and tell people to to change their config file and create a readme or an install file. (auto-install on index is best)
19-12-09
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by s-p-n
You should have an installation file....
Edit: I ran the query and got this message,
Fix that.. The tables were created though, and tell people to to change their config file and create a readme or an install file. (auto-install on index is best)
What's in the censored part?
19-12-09
s-p-n
Re: SimpleBB - Completely Re-engineered
Those stars are in your query, look at it.
19-12-09
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Aww, dang forum censoring.
---------- Post added at 07:05 PM ---------- Previous post was at 07:02 PM ----------
Edit: Now the query works ;)
what's the details to log in?
Edit 2: Figured out it's 'test' and 'test'...
Okay, so how do I post? I see text inputs but no button? (using firefox)
Also, the text at the top of the topics should be links so I can actually navigate around :/
Edit 3: Wait, the password is not test, when you enter the correct username and wrong password, no error message pops up. It's not very intuitive.. Maybe that's why I can't post?
Edit: Now the query works ;)
what's the details to log in?
Edit 2: Figured out it's 'test' and 'test'...
Okay, so how do I post? I see text inputs but no button? (using firefox)
Also, the text at the top of the topics should be links so I can actually navigate around :/
Edit 3: Wait, the password is not test, when you enter the correct username and wrong password, no error message pops up. It's not very intuitive.. Maybe that's why I can't post?
i should've explained lol.
In this edition, you can't really post yet lol.
I'm going to upload a new one in a couple of minutes, which includes membergroups, forum permissions, timzone management, and a bunch of other features. (It includes posting!)
---------- Post added at 08:48 PM ---------- Previous post was at 08:44 PM ----------
Edit: Now the query works ;)
what's the details to log in?
Edit 2: Figured out it's 'test' and 'test'...
Okay, so how do I post? I see text inputs but no button? (using firefox)
Also, the text at the top of the topics should be links so I can actually navigate around :/
Edit 3: Wait, the password is not test, when you enter the correct username and wrong password, no error message pops up. It's not very intuitive.. Maybe that's why I can't post?
Lol, you can just delete the hash in the db.
---------- Post added at 08:56 PM ---------- Previous post was at 08:48 PM ----------
Files updated.
New Features:
Forum Timezone
Posting Threads
Membergroups
Forum Permissions
Misc
Username: test; Pass: none
Viewing threads has NOT been coded yet; only displaying threads.
19-12-09
s-p-n
Re: SimpleBB - Completely Re-engineered
You've got allot of work to do, lol!
19-12-09
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Well, for me, what I thought was going to be the hardest was membergroups and forum permissions, but I got that done in just half an hour.
So yea, most likely gonna finish by New Years.
20-12-09
Generic230
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by xSilv3rbullet
Well, for me, what I thought was going to be the hardest was membergroups and forum permissions, but I got that done in just half an hour.
So yea, most likely gonna finish by New Years.
I'd assume you could do membergroups, forum permissions, and a blank forum with little to no functionality like this by following a tutorial.
20-12-09
xSilv3rbullet
Quote:
Originally Posted by Generic230
I'd assume you could do membergroups, forum permissions, and a blank forum with little to no functionality like this by following a tutorial.
The only reason I uploaded the files this time was so people like you wouldn't tell me that I copied a tutorial like the last time I posted this project.
---------- Post added at 04:48 PM ---------- Previous post was at 04:46 PM ----------
---------- Post added ---------- Previous post was at 04:48 PM ----------
Files Updated!
What's New:
No Permission Page
Replying
Other:
User and Pass: demo
Demo Site is now UP!
User and Pass: demo
20-12-09
s-p-n
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by Your Site
GrindSquad » SimpleBB » Headquarters » test » View
You need to make those links. Navigation is very poor.
I like what you have so far on the technical ends- You have more done than I thought ;)
The posting works and all that, but again, after I post I get lost. There's no navigation other than the top link to home. So fix that first, then work on the theme. After a user posts, it should redirect to their post or at least the topic it's on. Same when they create everything, just take them to the post.
Once that's done, maybe make an edit function so the users can edit their own posts.
22-12-09
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
For those of you who are having trouble posting/replying,
Open up newthread.theme.php and reply.theme.php in themes/Simple
and change
<script type=... />
to
<script type=...></script>
25-12-09
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
UPDATED
Links without 'http' or a protocol are automatically changed to http. Same goes with images.
27-12-09
Hidden
Re: SimpleBB - Completely Re-engineered
Tested it, it's pretty good. Simple, like the name.
The design is okay, it's not horribly bad once you install it, but if you just view it on his host it looks like crap since it's not your own.
Though a lot of features are missing, I hope it will grow into something big.
27-12-09
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by Hidden
Tested it, it's pretty good. Simple, like the name.
The design is okay, it's not horribly bad once you install it, but if you just view it on his host it looks like crap since it's not your own.
Though a lot of features are missing, I hope it will grow into something big.
I don't know whether I want to like or hate that comment. lol
:P
28-12-09
Hidden
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by xSilv3rbullet
I don't know whether I want to like or hate that comment. lol
:P
Neutral!
I would use the system if it was completed though.
28-12-09
s-p-n
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by xSilv3rbullet
UPDATED
Links without 'http' or a protocol are automatically changed to http. Same goes with images.
Nice, you got that working :thumbup1:
28-12-09
xSilv3rbullet
UPDATE: Added view thread UI.
-- Merged --
UPDATE: Download link added!
Happy New Year!
-- Merged --
Thread updated.
11-01-10
s-p-n
Re: SimpleBB - Completely Re-engineered
The Log out link doesn't seem to work anymore :/
03-02-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
It's been a long time since I've updated this thread, so lemme giv e you the updates!
Updates:
Spoiler:
New Theme Created
Maximize/Minimize Categories
Client Session instead of Server Session (Cookies)
Login Redirection
Logout Redirection
New/Read Thread (Controlled By Cookies)
Administrator CP (Started)
Category Description
Custom BBCode
Under Construction:
Spoiler:
Administrator CP
User CP
Advanced Editor
Private Messaging
Profile Backup and Restore
Moderator System
The Alpha II Release 1 will be released soon, once all the "Under Construction" stuff is done!
03-02-10
s-p-n
1 Attachment(s)
Re: SimpleBB - Completely Re-engineered
They say a picture's worth 1,000 words..
You're not ready to switch to cookies yet for you don't understand them. I think your little "Hack attempt detected" message is cute, but it sure is easy to get passed!
[Check attachment]
I don't know what Tony's PW is, but I know it's not "demo", and I also know I don't need to know it to access his account. If you had any kind of features I'd be able to edit/delete his posts and update his account.. But you don't, so.. there's not much I can do except add more threads/posts.
Get "Web Developer" and "Firebug" for firefox.. Oh, and for the 50th time, please find an alternative to the <center> tag... It's really not helping your cause if you can't figure out how to use mathematics to center elements instead of deprecated, faulty, text centering methods. :sleep:
Here's a little trick:
Code:
margin-left:auto;
margin-right:auto;
04-02-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by s-p-n
They say a picture's worth 1,000 words..
You're not ready to switch to cookies yet for you don't understand them. I think your little "Hack attempt detected" message is cute, but it sure is easy to get passed!
[Check attachment]
I don't know what Tony's PW is, but I know it's not "demo", and I also know I don't need to know it to access his account. If you had any kind of features I'd be able to edit/delete his posts and update his account.. But you don't, so.. there's not much I can do except add more threads/posts.
Get "Web Developer" and "Firebug" for firefox.. Oh, and for the 50th time, please find an alternative to the <center> tag... It's really not helping your cause if you can't figure out how to use mathematics to center elements instead of deprecated, faulty, text centering methods. :sleep:
Here's a little trick:
Code:
margin-left:auto;
margin-right:auto;
WOAH.
That's bad.
Forgot all about cookie vulnerabilities. T_T
---------- Post added at 07:13 PM ---------- Previous post was at 05:44 PM ----------
Patched.
Try it now. :P
04-02-10
jMerliN
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by xSilv3rbullet
WOAH.
That's bad.
Forgot all about cookie vulnerabilities. T_T
---------- Post added at 07:13 PM ---------- Previous post was at 05:44 PM ----------
Patched.
Try it now. :P
Why are you using cookies at all?
04-02-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by jMerliN
Why are you using cookies at all?
Aren't they supposed to be better for nonsensitive stuff?
Also, because i can control sessions better?
:O
04-02-10
jMerliN
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by xSilv3rbullet
Aren't they supposed to be better for nonsensitive stuff?
Also, because i can control sessions better?
:O
They are made completely useless by server-side session states. The only thing you could make an argument for us making a cookie to hold a session id key you store in a table somewhere the authenticates the person so they don't have to log-in at every visit of your forum. Anything outside of that is much more easily done (and makes more sense to do) using session variables on the server.
05-02-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by jMerliN
They are made completely useless by server-side session states. The only thing you could make an argument for us making a cookie to hold a session id key you store in a table somewhere the authenticates the person so they don't have to log-in at every visit of your forum. Anything outside of that is much more easily done (and makes more sense to do) using session variables on the server.
The only cookies I'm storing are the user id, user name, and user session.
THe session makes sure that the exploit spn showed doesn't work.
05-02-10
jMerliN
Re: SimpleBB - Completely Re-engineered
Why are you storing username and id?
05-02-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by jMerliN
Why are you storing username and id?
Hmm...good point.
Maybe not username
I could just update the session each time.
ID is kinda obvious lol...or not
In the sessions MySQL table, i have user id, so i could just select the user id and update it each time...?
05-02-10
Exiled Hero
Re: SimpleBB - Completely Re-engineered
Why are you creating the $sql object over and over again when you have included functions.php?
If you have created the $sql object in fucntions.php and include it, your other files will inherit it.
You have also created the object more than once inside the same file. it isn't needed. Once created, it can be used over and over.
if(!$conn || !$db) { die("Error connecting to the database."); }
Could of been..
PHP Code:
$conn = @mysql_connect($host, $user, $pass); $db = @mysql_select_db($db, $conn) or die("Error connecting to the database.");
be the same as above, just less execution time.
05-02-10
s-p-n
Re: SimpleBB - Completely Re-engineered
What data is used to make the hash for sbbsession?
Oh, and storing the user ID/username (either) is pointless or insecure. All you should need is a hash of the user+pass, (such as sbbsession, maybe). Nobody can crack that without knowing the user+pass, and they wouldn't need to if they did. It's simple.......... SO SIMPLE!
In fact, wait... Even That's redundant- to a point. You don't even need to hash the user+pass... Look, try a procedure more like this: [It's taboo to store raw password data in cookies, but someone actually has to steal their cookies for the particular site in order to get it. If a user is that insecure, technically they shouldn't be ENTERING a password in the first place.]
Code:
- User enters site.
- If Session[user] & Cookie[pass] are defined
- - continue
- else :
- - If Post[user] & Post[pass] are defined
- - - Cookie[user] = Post[user]
- - - Cookie[pass] = Post[pass]
- - If Cookie[user] & Cookie[pass] are defined
- - - Session[user] = sql_escape(Cookie[user])
- - - Session[pass] = md5(Cookie[pass])
- check_user_data(Session[user],Session[pass])
check_user_data returns the number of rows for a query that selects an id from the users table where user+pass are equal to their alter-ego session values.
If true, the user is seen as logged in. False, they are not logged in as anyone. No silly "Ah, being hacked!" messages, they're just immature. Also, there's no purpose for those lines in any application that doesn't expect to be getting hacked.
Since the cookies+session values are always the same (this should be declared at the top of all pages), then you only need to check the one with highest priority. Cookies are optional, if the user ticks the box that says "Remember Me", then they get a couple extra cookies, otherwise they only get the PHPSessID cookie.
The purpose of the cookies are solely for keeping a user logged in after the session is over. So if they visit your site with cookie variables, then they get turned into session variables, and cookies are never heard from again until the next time a session is created. That's why I chose to make them literally, identical of the form variables submitted.
If for whatever reason you change the way you encrypt the password or whatever, people who come back with user+pass cookies won't notice any problems, because the user+pass are compliant with the log-in form, and everything gets turned into Session[name]. All you'd have to change is the session variables, because they're the most reliable, and will surely have the data we need, whenever present. That data will come from the client [as GET, POST, or COOKIE]. But it will be escaped, in it's own way, before being compared with/inserted to the database in the form of a query.
Security is a breeze, just recognize every single point that makes a program insecure- that is, wherever the client can manipulate (or even view in some cases) ANY data on your server.
06-02-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by s-p-n
What data is used to make the hash for sbbsession?
Oh, and storing the user ID/username (either) is pointless or insecure. All you should need is a hash of the user+pass, (such as sbbsession, maybe). Nobody can crack that without knowing the user+pass, and they wouldn't need to if they did. It's simple.......... SO SIMPLE!
In fact, wait... Even That's redundant- to a point. You don't even need to hash the user+pass... Look, try a procedure more like this: [It's taboo to store raw password data in cookies, but someone actually has to steal their cookies for the particular site in order to get it. If a user is that insecure, technically they shouldn't be ENTERING a password in the first place.]
Code:
- User enters site.
- If Session[user] & Cookie[pass] are defined
- - continue
- else :
- - If Post[user] & Post[pass] are defined
- - - Cookie[user] = Post[user]
- - - Cookie[pass] = Post[pass]
- - If Cookie[user] & Cookie[pass] are defined
- - - Session[user] = sql_escape(Cookie[user])
- - - Session[pass] = md5(Cookie[pass])
- check_user_data(Session[user],Session[pass])
check_user_data returns the number of rows for a query that selects an id from the users table where user+pass are equal to their alter-ego session values.
If true, the user is seen as logged in. False, they are not logged in as anyone. No silly "Ah, being hacked!" messages, they're just immature. Also, there's no purpose for those lines in any application that doesn't expect to be getting hacked.
Since the cookies+session values are always the same (this should be declared at the top of all pages), then you only need to check the one with highest priority. Cookies are optional, if the user ticks the box that says "Remember Me", then they get a couple extra cookies, otherwise they only get the PHPSessID cookie.
The purpose of the cookies are solely for keeping a user logged in after the session is over. So if they visit your site with cookie variables, then they get turned into session variables, and cookies are never heard from again until the next time a session is created. That's why I chose to make them literally, identical of the form variables submitted.
If for whatever reason you change the way you encrypt the password or whatever, people who come back with user+pass cookies won't notice any problems, because the user+pass are compliant with the log-in form, and everything gets turned into Session[name]. All you'd have to change is the session variables, because they're the most reliable, and will surely have the data we need, whenever present. That data will come from the client [as GET, POST, or COOKIE]. But it will be escaped, in it's own way, before being compared with/inserted to the database in the form of a query.
Security is a breeze, just recognize every single point that makes a program insecure- that is, wherever the client can manipulate (or even view in some cases) ANY data on your server.
You make it seem so easy. lol :P
The time that the session was created is stored in the MD5 hash.
06-02-10
s-p-n
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by xSilv3rbullet
You make it seem so easy. lol :P
The time that the session was created is stored in the MD5 hash.
Because it IS easy.
You're just making it too hard. The time is not relavent, a user can define a time, and create an MD5 pass of it. It's very unlikely anyone will figure it out to the second, but it IS possible to crack without a traditional key, known as a password.
Also, your query for loading user data should look sort of like,
PHP Code:
..'WHERE user = "'.$_session['user'].'" AND pass = "'.$_session['pass'].'"'
07-02-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by s-p-n
Because it IS easy.
You're just making it too hard. The time is not relavent, a user can define a time, and create an MD5 pass of it. It's very unlikely anyone will figure it out to the second, but it IS possible to crack without a traditional key, known as a password.
Also, your query for loading user data should look sort of like,
PHP Code:
..'WHERE user = "'.$_session['user'].'" AND pass = "'.$_session['pass'].'"'
If they make up the time, they don't get access.
Flow:
Code:
Login
->
time() is hashed and inserted into mysql table, along with the userid and normal time
->
sbbsession is set (md5 hashed time)
username is set
id is set
->
each pageload checks to make sure the sbbsesion and id are in the same row, and that the session is active, if not, it locks out the user.
It probably still is hackable some way, but not in a way that i can see. :p
08-02-10
s-p-n
Re: SimpleBB - Completely Re-engineered
I cannot believe you insist on using a "time()" function in place of a password.
Your procedures are redundant, and do not make sense.
It is insecure because the time "tony" logged in last could be either achieved, if not guessed. If you don't believe a hacker could create an MD5 [or whatever hash used] of a time-stamp, you're in denial of the worst kind. The timestamp should be used to show an online/offline graphic for each user, it shouldn't be used to log that user in.
When logging in, does the user enter their ID and a timestamp? No, they do not. That would be silly. They enter a user and a pass, because it's a standard and recognizable way of logging in. It's normal, casual, and seems secure. The user understands, "I keep my password safe so I don't lose my account data."
Not only are you making your scripts run slower, but you're putting the very trust you may have with your users on the line when doing things differently just for the sake of being unique, or whatever the purpose may be. That's the concept I'm going to use in order to reach you. Look at things that work.. Like Windows, Servers, games, secure web-sites, banks- things that work.
They all follow a very simple procedure for security. A visible username (on a credit card, your credit card numbers), and a simple password. (on ATM cards, your PIN). Most things just use user+pass, but even when they don't, they use a very similar system for security. If the person knows the CC number and the pin, grant them access.
The biggest problem with credit and debit cards, is that some places don't ask for the pin, but instead a zip-code, or maybe nothing at all; just a quick swipe (which is basically just the numbers visible on the card). That's a problem because they don't use the stupid 4 digit PIN. It's like using a timestamp (zip-code) instead of a password (pin). It's unlikely, but achievable to figure out the zip-code/timestamp. Not as bad as asking for just the card number (or ID+user, in your previous issues), but still inferior a typical PIN number (or pass+user).
See, nothing replaces the simplicity of a password as the primary key for log-in credentials. Many huge corporations did it right, and many made very large mistakes. Learn from both. :D:
09-02-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by s-p-n
I cannot believe you insist on using a "time()" function in place of a password.
Your procedures are redundant, and do not make sense.
It is insecure because the time "tony" logged in last could be either achieved, if not guessed. If you don't believe a hacker could create an MD5 [or whatever hash used] of a time-stamp, you're in denial of the worst kind. The timestamp should be used to show an online/offline graphic for each user, it shouldn't be used to log that user in.
When logging in, does the user enter their ID and a timestamp? No, they do not. That would be silly. They enter a user and a pass, because it's a standard and recognizable way of logging in. It's normal, casual, and seems secure. The user understands, "I keep my password safe so I don't lose my account data."
Not only are you making your scripts run slower, but you're putting the very trust you may have with your users on the line when doing things differently just for the sake of being unique, or whatever the purpose may be. That's the concept I'm going to use in order to reach you. Look at things that work.. Like Windows, Servers, games, secure web-sites, banks- things that work.
They all follow a very simple procedure for security. A visible username (on a credit card, your credit card numbers), and a simple password. (on ATM cards, your PIN). Most things just use user+pass, but even when they don't, they use a very similar system for security. If the person knows the CC number and the pin, grant them access.
The biggest problem with credit and debit cards, is that some places don't ask for the pin, but instead a zip-code, or maybe nothing at all; just a quick swipe (which is basically just the numbers visible on the card). That's a problem because they don't use the stupid 4 digit PIN. It's like using a timestamp (zip-code) instead of a password (pin). It's unlikely, but achievable to figure out the zip-code/timestamp. Not as bad as asking for just the card number (or ID+user, in your previous issues), but still inferior a typical PIN number (or pass+user).
See, nothing replaces the simplicity of a password as the primary key for log-in credentials. Many huge corporations did it right, and many made very large mistakes. Learn from both. :D:
I think I kind of understand what you're saying, but how can I hacker get the exact time of the time that a user logged in?
For example, lets say i login at time() a.
a gets MD5d to lets say a1b2c3d4.
The hacker would first have to find the right value of sbbsession, and MD5 each attempt to try and get a1b2c3d4.
But I do know that this system has some problems, the system just got hacked again by a hacker.
And I wouldn't suggest MD5ing the password.
Easy text can be unhashed by using this: http://md5decrypter.com/
Of course, not a very complicated password, such as 10cw3rxz_r3FTaflje.
But what kind of user would want to remember that?
Maybe I'll use two hashes: MD5(SHA1())...
But that might cause some performance issues.
I'll decide later. :P
09-02-10
s-p-n
Re: SimpleBB - Completely Re-engineered
You can make your hashes hard to figure out...... When you insert time into the DB, you should do it using the timestamp/datetime feature through MySQL. It's faster than doing it through PHP and hashing it. There's really no reason to encrypt it, that's just an extra step, it doesn't help to make anything more secure.
Hashing the passwords are VERY important. Don't assume those md5 crackers have it all figured out. All they are is a list of values with MD5 matches. If your password is on the list it's bad. That doesn't mean you don't hash the passwords. You should also be using a "throw off" tactic or two. Like a salt, or the mixture of unchanging fields to increase the password strength.
Since you're forum is open-source, it can be backwards-engineered simply by downloading the source and seeing how it's encrypted. So keep it simple, but don't be an open book.
Still, there's no reason to have time() and encrypt it.
The user is supposed to remember their password, that's how they log-in???
They don't need to be concerned with the hash version of it, though their data shouldn't appear ANYWHERE on your server unhashed. That includes any databases.
Storing the raw password in the user's data (their cookies), is fine, obviously because it's their own computer, and their browser most-likely has tons of raw passwords laying around in the "Saved Passwords" bin.
I still don't get the time() as security. Yes, it's very unlikely to figure out, but it isn't a significant piece of data needed to access the account. It makes about as much sense as entering a Zip Code to verify you own a given Visa issued to an address in that zip-code.. I just don't get it..
The user enters a user+pass, but the database gets asked if the user, id, and timestamp exist? That doesn't make sense, now there's two ways to log-in, instead of just one. You must query for user+pass in the first log-in, why in any returning visits do you do it different? That's about twice as much code when you could've used the same exact procedural code for the same thing.
Every page load, log the user in the same. If sess[user]+sess[pass] is in the DB, the user must be correct.
When a form gets submitted, change form[user],[pass] to sess[user],[pass]. When there are cookies, change cookie[user],[pass] to sess[user],[pass], and you DON'T EVEN HAVE TO CHANGE THE LOG IN PROCEDURES!!!
See, it's 3x faster.
10-02-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by s-p-n
You can make your hashes hard to figure out...... When you insert time into the DB, you should do it using the timestamp/datetime feature through MySQL. It's faster than doing it through PHP and hashing it. There's really no reason to encrypt it, that's just an extra step, it doesn't help to make anything more secure.
Hashing the passwords are VERY important. Don't assume those md5 crackers have it all figured out. All they are is a list of values with MD5 matches. If your password is on the list it's bad. That doesn't mean you don't hash the passwords. You should also be using a "throw off" tactic or two. Like a salt, or the mixture of unchanging fields to increase the password strength.
Since you're forum is open-source, it can be backwards-engineered simply by downloading the source and seeing how it's encrypted. So keep it simple, but don't be an open book.
Still, there's no reason to have time() and encrypt it.
The user is supposed to remember their password, that's how they log-in???
They don't need to be concerned with the hash version of it, though their data shouldn't appear ANYWHERE on your server unhashed. That includes any databases.
Storing the raw password in the user's data (their cookies), is fine, obviously because it's their own computer, and their browser most-likely has tons of raw passwords laying around in the "Saved Passwords" bin.
I still don't get the time() as security. Yes, it's very unlikely to figure out, but it isn't a significant piece of data needed to access the account. It makes about as much sense as entering a Zip Code to verify you own a given Visa issued to an address in that zip-code.. I just don't get it..
The user enters a user+pass, but the database gets asked if the user, id, and timestamp exist? That doesn't make sense, now there's two ways to log-in, instead of just one. You must query for user+pass in the first log-in, why in any returning visits do you do it different? That's about twice as much code when you could've used the same exact procedural code for the same thing.
Every page load, log the user in the same. If sess[user]+sess[pass] is in the DB, the user must be correct.
When a form gets submitted, change form[user],[pass] to sess[user],[pass]. When there are cookies, change cookie[user],[pass] to sess[user],[pass], and you DON'T EVEN HAVE TO CHANGE THE LOG IN PROCEDURES!!!
See, it's 3x faster.
Well, this is what I'm doing (New way; fixed the hack :)):
Code:
Login
->
Set sbbsession (md5(sha1(time()).sha1(username).sha1(password))
No more username and id stored in cookies
->
On each pageload, username and ID are assigned
$GLOBALS['id'] = getId($_COOKIE['sbbsession']); (pseudo-code)
->
Now the only way it can be hacked is if the hacker is succesfully able to get the correct SHA1 values of the login time, the username, and the password, and then MD5 it all.
I think the query on each pageload might be inefficient though...
I might go for a recode in Beta. Maybe.
Current Structure
Code:
Load Page
->Include Config
->Include Functions
->Include Settings (this is where the cookie checking and assigning occurs)
->Include Theme
->Execute htmlHeaders() in theme
->Execute index() in theme
-> Execute body() from index()
->Done Loading
But this really isn't good.
The theme stylist still needs to know some PHP and how to use mysql_fetch_array().
Basically, to get the forums, this is what you use:
Code:
include("functions.php");
$cats = getCategories();//Returns a mysql query
while($array = mysql_fetch_array($cats)
{
}
So as you can see, the stylist still needs to know some BASIC to INTERMEDIATE PHP skills.
Also, the structure doesn't allow add-ons.
So I'm hoping for this to be the new structure some day.
Code:
Load Page
->
Include files
->
Load Add-on Classes
->
Load "ThemeLoader.php" //Maybe styling could be a custom script language
->
Use the code generated by ThemeLoader
->
Include Add-on code
->
Display
->
Done Loading
10-02-10
s-p-n
Re: SimpleBB - Completely Re-engineered
How does $GLOBALS['id'] get checked with the database?
11-02-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by s-p-n
How does $GLOBALS['id'] get checked with the database?
That's basically what's happening on each page load.
Ineffecient, I know. :p
11-02-10
s-p-n
Re: SimpleBB - Completely Re-engineered
I mean the actual code. The log-in, the cookie set, and the user data fetch into $globals[].
Using the code you have now, what if the sbbsession is:
Code:
" OR 1;SELECT id as userid FROM users WHERE id=1--
The code you're actually using is different than the above, or that injection would surely return the user ID I was looking for.
It didn't work as expected, but your site doesn't think I'm trying to hack it, and assumes a user is logged in, I just couldn't get the userid returned correctly.
Maybe it has something to do with the fact tonyyyyy doesn't have a row in the session table, which would be cheating on your part, because if 'demo' is the only user in the table, then of course nobody else is going to get logged in.. You'd just be cheating yourself if you made it any more secure than a typical build would be. Such as, only having a single user account in the "session" table. It could be looked at as secure, but what if you have two users on the forum at the same time. I mean come on.. How common is that?
12-02-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by s-p-n
I mean the actual code. The log-in, the cookie set, and the user data fetch into $globals[].
Using the code you have now, what if the sbbsession is:
Code:
" OR 1;SELECT id as userid FROM users WHERE id=1--
The code you're actually using is different than the above, or that injection would surely return the user ID I was looking for.
It didn't work as expected, but your site doesn't think I'm trying to hack it, and assumes a user is logged in, I just couldn't get the userid returned correctly.
Maybe it has something to do with the fact tonyyyyy doesn't have a row in the session table, which would be cheating on your part, because if 'demo' is the only user in the table, then of course nobody else is going to get logged in.. You'd just be cheating yourself if you made it any more secure than a typical build would be. Such as, only having a single user account in the "session" table. It could be looked at as secure, but what if you have two users on the forum at the same time. I mean come on.. How common is that?
AH.
Thank you.
I forgot all about SQL Injection. :)
The row is created when you login, and the 'active' column is set to 0 when you log out. This way, the admin can view logs of all sessions (Time logged in, time spent, IP, etc). The admin can also delete the session log, if too much memory gets used up.
So basically, the only way you're going to be able to get the row inserted would be going through the login.
12-02-10
s-p-n
Re: SimpleBB - Completely Re-engineered
Well in any case, it's becoming much better. ;) It's not the most normal forum, but it's becoming more promising anyway. I still think MD5ing everything is redundant, only the password should really be hidden from the eyes. The reasoning why it's done differently is a little better defined, but I still think it needs a little work. I can't pin-point exactly what it is yet, but something seems incomplete. Good work so far, keep moving forward adding more functions like edit/delete. As you're doing that, keep in mind Administration, and most importantly security.
You can use a simple where clause for the posts/threads:
Code:
/* Update Query.. */ WHERE `rank_id` = "'.$GLOBALS['rank_id'].'" OR `user_id` = "'.$GLOBALS['user_id'].'"
The key, is to be absolutely confident and sure that your variables cannot get redefined by a malicious user. That is the one sure key to being secure. If you can keep an array of safe, secure variables extracted directly through a confirmed database query, you can do allot of very cool things. [Nothing gets passed, 'SELECT id, rank_id FROM users WHERE user="user" AND pass="pass"', for instance.. You must also be sure they cannot be redefined later in the script]. You can use your own methods, though simpler procedures are much easier to keep track of on allot of levels.
Things that get loaded on every page must be as simple as possible, for that's the very heart of the engine, that can slow down every page. For example, using SESSION variables allows a 'first-time-only' load on many variables. Site settings, global theme properties, and even user-data can be loaded one time from the database, only on the first page-load. Could be done with a single line of code; If the sessions exist, then they don't get loaded from the database. Logically speaking,
PHP Code:
if(!isset($_SESSION['site_settings']))
{
$site_settings = new site_load_settings();
$site_settings->create_session('_site'); //always use a prefix for things like this
}
If you're perfectly confident the session will be what it needs to be, this saves allot of execution time.
mysql_query('UPDATE `posts` SET `title` = "'.$post_title.'",
`body_HTML` = "'.$post_body_HTML.'",
`body_BB` = "'.$post_body_BB.'"
WHERE `id` = "'.$post_id.'"') or $errMsg = mysql_error();
if(strlen($errMsg)<1)
$goodMsg = 'Post Updated!';
?>
<form method="post" action="">
<input type="hidden" name="post_id" value="3" />
<input type="text" name="post_title" value="The Original Title" />
<br />
<textarea name="post_body">[b]Original Post Body with [u]BBcode[/u][/b]
...
</textarea><br />
<input type="submit" name="edit_post" value="Update Post" />
</form>
If you can find all the security risks in there, and you take in what I said above, you should be fairly confident with security.
So, see anything wrong in the code above?
13-02-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by s-p-n
Well in any case, it's becoming much better. ;) It's not the most normal forum, but it's becoming more promising anyway. I still think MD5ing everything is redundant, only the password should really be hidden from the eyes. The reasoning why it's done differently is a little better defined, but I still think it needs a little work. I can't pin-point exactly what it is yet, but something seems incomplete. Good work so far, keep moving forward adding more functions like edit/delete. As you're doing that, keep in mind Administration, and most importantly security.
You can use a simple where clause for the posts/threads:
Code:
/* Update Query.. */ WHERE `rank_id` = "'.$GLOBALS['rank_id'].'" OR `user_id` = "'.$GLOBALS['user_id'].'"
The key, is to be absolutely confident and sure that your variables cannot get redefined by a malicious user. That is the one sure key to being secure. If you can keep an array of safe, secure variables extracted directly through a confirmed database query, you can do allot of very cool things. [Nothing gets passed, 'SELECT id, rank_id FROM users WHERE user="user" AND pass="pass"', for instance.. You must also be sure they cannot be redefined later in the script]. You can use your own methods, though simpler procedures are much easier to keep track of on allot of levels.
Things that get loaded on every page must be as simple as possible, for that's the very heart of the engine, that can slow down every page. For example, using SESSION variables allows a 'first-time-only' load on many variables. Site settings, global theme properties, and even user-data can be loaded one time from the database, only on the first page-load. Could be done with a single line of code; If the sessions exist, then they don't get loaded from the database. Logically speaking,
PHP Code:
if(!isset($_SESSION['site_settings']))
{
$site_settings = new site_load_settings();
$site_settings->create_session('_site'); //always use a prefix for things like this
}
If you're perfectly confident the session will be what it needs to be, this saves allot of execution time.
mysql_query('UPDATE `posts` SET `title` = "'.$post_title.'",
`body_HTML` = "'.$post_body_HTML.'",
`body_BB` = "'.$post_body_BB.'"
WHERE `id` = "'.$post_id.'"') or $errMsg = mysql_error();
if(strlen($errMsg)<1)
$goodMsg = 'Post Updated!';
?>
<form method="post" action="">
<input type="hidden" name="post_id" value="3" />
<input type="text" name="post_title" value="The Original Title" />
<br />
<textarea name="post_body">[b]Original Post Body with [u]BBcode[/u][/b]
...
</textarea><br />
<input type="submit" name="edit_post" value="Update Post" />
</form>
If you can find all the security risks in there, and you take in what I said above, you should be fairly confident with security.
So, see anything wrong in the code above?
I'm going to guess that post_body isn't escaped?
O_O
15-02-10
s-p-n
Re: SimpleBB - Completely Re-engineered
There's a few more things wrong, too. $post_body_BB is the only $post_body variable you can know for sure can get cracked. The one that goes through the function depends on whether or not the function protects the DB from SQL, and mark-up from XSS injections. Since BBcode is for security reasons in the first place, it's fine to assume the function has what it needs to be secure. (In reality you'll be making it, so it's your job to make sure)
The body isn't the only issue though.
Think in the WHERE clause, there's still a few things wrong with it. [All revolving around one single concept, but 1 var is wrong, and 1 or 2 are missing.
16-02-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by s-p-n
There's a few more things wrong, too. $post_body_BB is the only $post_body variable you can know for sure can get cracked. The one that goes through the function depends on whether or not the function protects the DB from SQL, and mark-up from XSS injections. Since BBcode is for security reasons in the first place, it's fine to assume the function has what it needs to be secure. (In reality you'll be making it, so it's your job to make sure)
The body isn't the only issue though.
Think in the WHERE clause, there's still a few things wrong with it. [All revolving around one single concept, but 1 var is wrong, and 1 or 2 are missing.
I'm just going to take a guess here...
If the user can modify the ID, then they can update another post.
O_O
16-02-10
s-p-n
Re: SimpleBB - Completely Re-engineered
Right, now if there was only a way to build the system around that very problem. In the `posts` table, (using the example), there should be a column for the Author's ID. Assuming the user-name is possible to change in the future, only the User ID [which should never change] should be used.\
Now wait, so the hacker would only need to know & crack the user's ID and the post ID? That's really easy- especially if the form has the post ID, changeable and submittable, in the source code. We need a way to track the post from the form to the action. The post's ID is the smallest and most distinct, and therefore the obvious culprit, so we use that.
So what about the user's ID? Well if you use a secure global array of variables like I talked about in some of the previous posts, it seems like all the variables are in place.
WysGui CMS has a new feature, one or more users (in addition to their rank), can have the gratitude of being called "Super Admin". Now, Admins and Mods may be able to edit posts, but we'll deal with that later. The Super Admin is the ruler of the entire site, or forum in your case, so thus should be granted permission to do EVERYTHING.
So in the WHERE clause, it needs to say.....?
(Stretch to do all of your security work in the WHERE clause. It's more efficient than creating conditional statements in PHP.)
16-02-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by s-p-n
Right, now if there was only a way to build the system around that very problem. In the `posts` table, (using the example), there should be a column for the Author's ID. Assuming the user-name is possible to change in the future, only the User ID [which should never change] should be used.\
Now wait, so the hacker would only need to know & crack the user's ID and the post ID? That's really easy- especially if the form has the post ID, changeable and submittable, in the source code. We need a way to track the post from the form to the action. The post's ID is the smallest and most distinct, and therefore the obvious culprit, so we use that.
So what about the user's ID? Well if you use a secure global array of variables like I talked about in some of the previous posts, it seems like all the variables are in place.
WysGui CMS has a new feature, one or more users (in addition to their rank), can have the gratitude of being called "Super Admin". Now, Admins and Mods may be able to edit posts, but we'll deal with that later. The Super Admin is the ruler of the entire site, or forum in your case, so thus should be granted permission to do EVERYTHING.
So in the WHERE clause, it needs to say.....?
(Stretch to do all of your security work in the WHERE clause. It's more efficient than creating conditional statements in PHP.)
Wait, are you saying that the user CAN edit their ID and post id?
---------- Post added at 11:10 AM ---------- Previous post was at 11:07 AM ----------
Quote:
Originally Posted by s-p-n
You can use a simple where clause for the posts/threads:
Code:
/* Update Query.. */ WHERE `rank_id` = "'.$GLOBALS['rank_id'].'" OR `user_id` = "'.$GLOBALS['user_id'].'"
Just actually read the query lol.
That wouldn't work.
You see, if the user would change ranks (like becoming a mod or getting promoted to a higher rank), that wouldn't work.
Lets say user A posts thread X. Currently, user A has a rank with an id of '1'.
User A posts another thread, lets say Y.
Now, after he posts Y, he's promoted to lets say, a rank called
'XY' with an id of 2
Now, he can't edit his posts any more, since his rank isn't the same.
Oh wait, you're using OR.
But then you're relying on the user id, which you just said is bad. :O
18-02-10
s-p-n
Re: SimpleBB - Completely Re-engineered
The key is to have trusted variables defined on every page of the site. If you don't have anything secure to fall-back on, nothing can be secure.
Based on that, the key is having a secure log-in system to determine the user's correct ID. That's all fine and simple, DO NOT store it anywhere it can be changed/seen by the user.
If you can successfully determine a user's ID beforehand [As in, 100% secure, no way for a user to view/change it], then you can (and should) rely solely on that piece of data.
Why rely solely on a processed user ID? Because it leaves one space for a hacker, the user ID. (Which means less work for the programmer ;). So if one changes their user ID, they can hack the shit out of your site, true. But again, the issue isn't how bad they can hack the site if they crack the user ID, the issue is making security simple, and moving forward. Of course, the simpler security is, the easier it is to handle.
Assuming you have that down, let's move on to what I meant by the ranking system.
Notice in RageZone, things are multithreaded. As a Moderator, I have permission to moderate "Coder's Paradise", for example. My range extends in all sub-forums, threads, and posts. My user ID doesn't match yours, or anyone elses, but I can still edit yours and others posts. How is that possible?
The answer is actually rather simple. It's brought to you by "OR", obviously, but how does the post know I have permission? Even harder, how does it know other moderators do not have permission? I'm not going to get into that.. Let's assume every moderator can edit posts in those sections.
The rank_id field in the database, doesn't fall-back on the submitters rank. No no no, it's the rank inherited from the permission-base of your forum. Has absolutely no reference to the user's rank when it's added into the posts table. It should be inherited from the forum->sub-forum->thread, in reverse order; (furthest_parent->closest_parent-> post). If that's too complicated, which it sounds daunting to say the least, you can keep it simple.
Let's say the Moderator's rank ID is 3.
Now, assuming the undefined variables, 'rank_id', and 'user_id' are defined securely above, our query can look like this:
Code:
UPDATE `posts` SET '.$post_set.'
WHERE `id` = "'.mysql_real_escape_string($_POST['id']).'" /* ? = ? */
AND (
`rank_id` = "'.$user['rank_id'].'" /* 3 = ? */
OR `user_id` = "'.$user['id'].'" /* ? = ? */
)
The only way to update the post is if the post_id is correct, and also, the user must be the author, or a moderator. [ 3 = ? ]
*Note the importance of parenthesis in SQL clauses.
Security doesn't come easy unless you design it easy. I'm not going to "guarantee" everything's going to work just fine if you take all my advice, I'm more trying to help you make sense of the reasons things are or are not secure.
For example, the only thing stopping a hacker from cracking the query above is, well actually a few things. Each variable determined by a user can possibly open a door for a hacker. For example, I showed a few posts back a form which contained a hidden field with the post ID. Nothing stops a hacker from changing that post ID to any post in the database. However, the hacker's user ID and rank ID prevent them from updating any post except their own. So they can't get through that without a SQL injection. If you prevent those, then it's full-proof. The only way the hacker can get through is changing his user-id. MAKE THAT IMPOSSIBLE TO DO AT ANY AND ALL COSTS! Keep the cost cheap (metaphor; simple) as possible, but at any cost, keep the site safe.
If the user+pass are correct, grab the user's data: id, rank_id. Each page-load, if the user is not defined, define them securely. If they are defined, ignore. Well that only works if you use SESSIONS as the main thing, which you should.
You don't have to use sessions, it's just more efficient and easier in the long-run.
09-03-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
...and we're back!
SimpleBB development has officially started...
not now,
and not now either,
nor now,
nope,
uh uh,
not here,
but here!
That's right, development is on!
11-03-10
s-p-n
Re: SimpleBB - Completely Re-engineered
Release it with a SQL import file.
Do you have a release you can throw at me?
12-03-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
...nope!
:P
I'm half way through to Alpha II release.
08-04-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
thread updated!
Read the main post for more details
13-04-10
InMemory
Re: SimpleBB - Completely Re-engineered
Awesome work i guess this is from scratch then :D. i may fiddle with it see what i can do with it :D PM me if you need any code snippits or anything i would be happy to help
01-05-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by .data
Awesome work i guess this is from scratch then :D. i may fiddle with it see what i can do with it :D PM me if you need any code snippits or anything i would be happy to help
Sorry for this late reply.
I currently am not looking for any help, but I would appreciate it if you would test it for bugs.
A new build will be uploaded on May 15th, so stay tuned!
15-06-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quick update...
Editing has now been enabled!
Work on the AdminCP has continued, and you can now set board properties and create/delete categories.
15-06-10
Markshall
Re: SimpleBB - Completely Re-engineered
As said, the design sucks but features seem good :]
17-06-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by m0nsta.
As said, the design sucks but features seem good :]
I don't know whether to say thanks, or what.
:P
When SimpleBB is released, you'll be able to create your own themes.
The current theming system is kinda, for a lack of a better word, bad; you have to know PHP/HTML to create a style.
All the functions however (such as getForums(), getThread($tid)) are already in data/functions.php, so when you create a theme, all you have to do is utilize those functions and place the output they return in the areas you wish to put them in.
18-06-10
Winter
Re: SimpleBB - Completely Re-engineered
demo site said server not found. Couldn't gain a demo access. :L
19-06-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by Typhoid
demo site said server not found. Couldn't gain a demo access. :L
Sorry, I changed domains and didn't fix it. :P
Post updated, but here's the new link anyways:
The style is clashy, you need to work more on the CSS/XHTML. It doesn't seem very organized and it just seems like it wouldn't hold up very well with a lot of traffic.
29-07-10
xSilv3rbullet
Re: SimpleBB - Completely Re-engineered
Quote:
Originally Posted by josho192837
This looks terrible. /:
The style is clashy, you need to work more on the CSS/XHTML. It doesn't seem very organized and it just seems like it wouldn't hold up very well with a lot of traffic.
If you read the previous posts, you'll see that I'm not very good with designing.
I'm more of a programmer.
But that's not an excuse for a bad style, now is it?
And it can hold up with a lot of traffic, I've recoded parts to make it more efficient.
