Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

HTMLy: Databaseless Blogging Platform (Flat-File Blog)

github.com

Post reply on HN
Print view View original

51–60 of 66 posts

Re: HTMLy: Databaseless Blogging Platform (Flat-File Blog)

#51

Post by yen223 »

vidarh wrote: post #30
spookylukey wrote: post #25

You should really use SQLite! You will either end up with an ad hoc, informally-specified, bug-ridden, slow implementation of half of SQLite ... or, you will fail to even attempt the features that SQLite gives you - such as locking and dealing with concurrency - and you will have bugs. For example, you use file_put_contents. See this comment: http://www.php.net/manual/en/function.file-put-contents.php#... Please don'…

A blogging platform for personal use is not magic. Avoiding things like concurrency problems in small platforms like this is often trivial. Personally I also use a flat file blogging platform, and I explicitly rejected putting stuff in a database because I want to be able to edit the articles with emacs and check them into a git repository. Concurrency in my case is a non-issue because, well, there's only one of me.…

If you don't want to use a database, go for one of the many static site generators. That way, you won't even need to muck around with PHP.

This project as it stands, quite frankly, looks like the worst of both worlds.

Re: HTMLy: Databaseless Blogging Platform (Flat-File Blog)

#52

Post by icebraining »

stevekemp wrote: post #46
icebraining wrote: post #38

Earlier quoted context omitted.

It's interesting that we're still writing such applications by hand. One thing that interested me when I learned about CouchDB was the possibility of skipping that and just exposing the database to the browser, with a few schemas and a couple of data validation functions configured. After all, that system is almost a dumb HTTP storage mechanism.

Presumably that means that users can mass-scrape the submitted comments though? (Potentially allowing the email addresses users submitted to be harvested.) Other than that it doesn't seem like an unreasonable approach.

Why can't they mass scrape your service, though? After all, what you built is essentially a very specialized REST database.

As for harvesting email addresses, I think you could solve that by using a CouchDB view, which is essentially a function that processes and returns JSON documents. In this case, it could just delete the "email" key and return the rest.

You would probably still need to block the direct access to the document via frontend proxy, since I don't think Couch allows you to specify fine-grained per-user permissions, which is definitively a drawback.

Alternatively, since you're already willing to send hashed versions of the emails (as Gravatars), you could just store only the hashes in the first place, and never commit the plaintext to disk.

Re: HTMLy: Databaseless Blogging Platform (Flat-File Blog)

#53

Post by kijin »

danpros wrote: post #36
kijin wrote: post #27

I hate non-standard stuff like this, even though I myself do similar things all over the place. It's the kind of the thing that's OK if you do it to yourself, but immediately rings an alarm when it is distributed to the general public. When you're already doing something non-standard by using a flat file instead of a well-known DB format, you might as well use standards in other places so that people have fewer reaso…

The initial version was using a standard markup for the title but I change it due to avoid if there is a double h1 :) For the next point as tags, dates, I chose to put it as a filename for the sake of speed.

In HTML5, it's OK to have multiple tags in a page, provided that they belong to separate sections, articles, etc.

Re: HTMLy: Databaseless Blogging Platform (Flat-File Blog)

#54

Post by stevekemp »

icebraining wrote: post #52
stevekemp wrote: post #46

Earlier quoted context omitted.

Presumably that means that users can mass-scrape the submitted comments though? (Potentially allowing the email addresses users submitted to be harvested.) Other than that it doesn't seem like an unreasonable approach.

Why can't they mass scrape your service, though? After all, what you built is essentially a very specialized REST database. As for harvesting email addresses, I think you could solve that by using a CouchDB view, which is essentially a function that processes and returns JSON documents. In this case, it could just delete the "email" key and return the rest. You would probably still need to block the direct access to…

I might have been making assumptions on CouchDB which aren't valid - that remote users could query all documents (== pages) to get the comments.

With my thing yes it can be crawled, since requests to /comments/ID will return the JSON comment-data. However there is no enumeration of the valid IDs possible, short of a dictionary attack. (This is where I was thinking that exposing CouchDB might expose more data.)

I did consider not storing emails, and for my use-case that's fine, but I figured sooner or later somebody will want to access them so ruling it out unduly would eventually result in a bug report.

Re: HTMLy: Databaseless Blogging Platform (Flat-File Blog)

#55

Post by icebraining »

stevekemp wrote: post #54
icebraining wrote: post #52

Earlier quoted context omitted.

Why can't they mass scrape your service, though? After all, what you built is essentially a very specialized REST database. As for harvesting email addresses, I think you could solve that by using a CouchDB view, which is essentially a function that processes and returns JSON documents. In this case, it could just delete the "email" key and return the rest. You would probably still need to block the direct access to…

I might have been making assumptions on CouchDB which aren't valid - that remote users could query all documents (== pages) to get the comments. With my thing yes it can be crawled, since requests to /comments/ID will return the JSON comment-data. However there is no enumeration of the valid IDs possible, short of a dictionary attack. (This is where I was thinking that exposing CouchDB might expose more data.) I did…

I might have been making assumptions on CouchDB which aren't valid - that remote users could query all documents (== pages) to get the comments.

Yes, you'd probably need to block that URL with a proxy, and only allow single page views to be requested. I think this is definitively a shortcoming of the BD; it should allow finer grained permissions.

However there is no enumeration of the valid IDs possible, short of a dictionary attack.

Well, by default CouchDB uses UUIDs, so enumeration shouldn't be possible either. Of course, both are subject to simple scraping of the HTML pages; a simple wget + grep can probably list them all, so you don't gain much, except for private pages you might have.

I did consider not storing emails, and for my use-case that's fine, but I figured sooner or later somebody will want to access them so ruling it out unduly would eventually result in a bug report.

Fair enough. I actually don't think CouchDB, as it is now, would necessarily be a better solution than yours. But the question is, why not? I believe the direction is correct, but the current implementation falls short, and that's a shame.

Re: HTMLy: Databaseless Blogging Platform (Flat-File Blog)

#56

Post by gararapa »

danpros wrote: post #47
gararapa wrote: post #32

Why are you versioning the dependencies?

Did you mean the PHP 5.3? There is a library that requires PHP 5.3 or greater.

No. I meant the dependencies contained in vendor/ directory. And the composer.phar file itself. Is there a reason why you're versioning these things?

Re: HTMLy: Databaseless Blogging Platform (Flat-File Blog)

#58

Post by danpros »

gararapa wrote: post #56
danpros wrote: post #47

Earlier quoted context omitted.

Did you mean the PHP 5.3? There is a library that requires PHP 5.3 or greater.

No. I meant the dependencies contained in vendor/ directory. And the composer.phar file itself. Is there a reason why you're versioning these things?

Basically I just want all dependencies works as well as when I test it, and in accordance with the guidelines getcomposer.org :)

This platform prioritizes writing through the admin panel, the convenience for users, particularly for non programmmer or for those who are not familiar with coding at all.

If you have other views, you can contribute to the project, so that we can discuss it further.

Re: HTMLy: Databaseless Blogging Platform (Flat-File Blog)

#59

Post by danpros »

kijin wrote: post #53
danpros wrote: post #36

Earlier quoted context omitted.

The initial version was using a standard markup for the title but I change it due to avoid if there is a double h1 :) For the next point as tags, dates, I chose to put it as a filename for the sake of speed.

In HTML5, it's OK to have multiple tags in a page, provided that they belong to separate sections, articles, etc.

If you try it, you will realize that to write an article using the admin panel is quite user friendly :)

Re: HTMLy: Databaseless Blogging Platform (Flat-File Blog)

#60

Post by danpros »

yen223 wrote: post #51
vidarh wrote: post #30

Earlier quoted context omitted.

A blogging platform for personal use is not magic. Avoiding things like concurrency problems in small platforms like this is often trivial. Personally I also use a flat file blogging platform, and I explicitly rejected putting stuff in a database because I want to be able to edit the articles with emacs and check them into a git repository. Concurrency in my case is a non-issue because, well, there's only one of me.…

If you don't want to use a database, go for one of the many static site generators. That way, you won't even need to muck around with PHP. This project as it stands, quite frankly, looks like the worst of both worlds.

> This project as it stands, quite frankly, looks like the worst of both worlds.

It's okay if you think like that, but you should try it first and then compare it with other similar solutions (i.e Ghost).

Post reply on HN