

Show HN: BlogFile; ~3000 line, single file PHP blog software - samuellevy
http://blog.samuellevy.com/index.php?p=post&id=10

======
quadhome
Other micro (as in code size) blogs:

* Blosxom <http://www.blosxom.com/> (440 lines)

* Trivium <https://github.com/chneukirchen/trivium/> (172-ish lines)

* werc <http://werc.cat-v.org/> (more like a micro-meta-CMS)

------
cfinke
It's an interesting exercise, although the first downside I noticed of the
"one file" mantra is that all of the CSS is served inline in every response.

Also, you may want to consider handling MySQL errors in a manner other than
just printing it to screen along with the query. At the very least, log them
somewhere where you'll be alerted of the error. As a user, seeing "MySQLi
Error: [...]" doesn't help me or you.

It'll be interesting to see if you continue the project and how far you take
its functionality. Some of my co-workers were just today discussing the
tendency to want to rewrite a system from scratch in order to simplify it and
avoid any problems with backwards compatibility, only to slowly find yourself
rewriting the "unnecessary" features from which you were trying to escape.

~~~
samuellevy
The CSS isn't actually that large. The entire home page (CSS included) is
about 4-5KB. The analytics code from google is three times the size of the
rest of my page.

What MySQL error did you run in to? You're right that I should probably hide &
log them, but at this stage logging is a low priority. I'll add it in later
on.

This is built largely for personal use, so I'll only implement features that I
feel I actually need, and even then they may not all make it into the main
code base.

~~~
cfinke
I didn't encounter any errors; my comments were just from browsing the source.

------
cheald
Your brute-force protection is:

a) bypassable (by simply not sending a session cookie), and

b) exploitable to DOS your server (PHP processes are single-threaded so
sleep() is basically just a blocking call) - I could just bombard your server
with a bunch of login requests to eat up all of the connection slots that end
up sleeping for a very long time. You can't serve legit traffic when all of
your PHP workers are off sleeping for six hours.

~~~
samuellevy
Yeah, that's pretty fair. It's little more than protection against automated
scripts which scrape the net looking for easy ways in (as is my comment spam
protection).

There's not a huge amount to be gained by building a super sophisticated anti-
spam or anti-brute-force system until it's likely that someone will actually
write an attack specifically for this software, and seeing as I built it
mostly for my own use, anyone who did that is probably just trying to do
damage to me (for whatever reason).

~~~
cheald
I'd at least take the sleep() out. That way, you get rid of the super easy DoS
vector. If someone were to deploy this on their shared webhosting, they'd find
themselves with a very upset host.

You're using the very fast md5/sha1 (why both?) functions for password
hashing. PHP has bcrypt support; why not use it instead? That a) accomplishes
the goal of making brute-force untenable, and b) further protects your users'
passwords in case you ever accidentally introduce a SQL injection (which, if
you continue to work on this project, you probably eventually will; no
personal offense - that's a big part of why more comprehensive frameworks that
try to abstract away from raw SQL exist. Human make mistakes, especially in
6000-line superfiles ;)

Edit: Also, your password updates (and other POST-ish operations, except
commenting) don't have any kind of CSRF protection, so I could reset your
password if I can get you to interact with a page where I've set up some
"proof of concept" of something you might find interesting, with a form to
post to yoursite.com/?p=savesettings&password=0wned, at which point I just log
in and take admin control of the site. Since you don't ask for a username on
login, such an attack would be _extremely_ trivial.

(As another commenter mentioned, it's easy to discover that much of the
'bloat' is actually stuff you want!)

------
drivebyacct2
This is scary. All in one file. PHP. CSS/HTML/PHP all in one file.

I don't mean to be a jerk, but what problem does this solve, or was it simply
a personal challenge/adventure?

edit: Some of this is answered on the GitHub page. I guess I'm going to be
concerned if someone is worried about how to unzip a file on a server...

~~~
samuellevy
Mostly a personal challenge. I was also sick of things being over-bloated.

I wanted to see what I could get away with in a single file without things
getting too large to manage. It's getting close to unmanageable now, but I
think it's still OK.

~~~
drivebyacct2
I don't mean to be a jerk, but multiple files does not mean bloat. In fact,
shoving a bunch of orthogonal functionality into a single file screams bloat
more than 3 thousand-line files, or 6 500-line files.

~~~
Produce
Also not meaning to be a jerk, but that file has a thousand line switch
statement. For the love of all that is holy, won't someone think of the
children?!

~~~
samuellevy
Hey, at least I'm not using GOTOs.

In due course, I'll probably re-write large parts of it, and make it more...
"clean", but this really was a quick project hacked out in my spare time over
a couple of weeks.

