h2g2 The Hitchhiker's Guide to the Galaxy: Earth Edition

It's not really a rip-off at all, but I've been working for a while on a bunch of php scripts and a database that basically serves up dynamic content (as standards-compatible as possible of course).

I've decided to open it up a bit so that you guys can take a look. You can get a good idea by exploring around http://frankieroberto.com/fra/core/

It's a bit fragile at the moment, and there's a few loop holes, so try not to break anything. I haven't uploaded the edit/add article script for now because there's no user/password protection. But you can do everything else.

So, feedback/ideas please!

Pretty nice. I'm glad you chose to copy the look of alabaster rather than any of the others. I've been thinking of working on something along these lines and I might get in touch at some point.

I've actually got some different CSSs which mimic the other skins. They're all uploaded but aren't linked to. Have a look now for the Goo one.

I still only see the alabaster one...?

I changed it back. But if you use Mozilla you can see it again using the alternative stylesheet...

Have you considered sending those stylesheets to the H2G2 team? It looks like it could save them time in the future when the BBC finally lets them upgrade the site to CSS instead of HTML Transitional...

OK I'll take a look next time I boot in Linux.

The idea I had in mind for a similar project is (roughly speaking) as follows, let me know what you think. If you're interested we could perhaps work on it as a joint project.

I decided on a tree based structure with a unix-like symbolic link (symlink) feature as well. This has the advantage that it is the "natural" way or organising a public forum and the "natural" way of organising a filesystem. In theory, the exact same code could deal with articles and forums, including forums attached to articles.

The motivation for my scheme is (a) encourage good logical structure to sites, forums, etc., this would make finding information more consistent, quicker and more efficient, (b) make it easy to synchronise content between the server and local machine, (c) allow the user to customise how they organise the information presented by the site locally.

The user interface would be a collapsible tree like you get in the "explorer view" in windows, or like most graphical usenet readers use. Each node of the tree could have one or both of (1) a piece of content, this could be an HTML file, text file, image or whatever, (2) an attached subtree. Additionally, each node could have various metadata attached, e.g. "Author=Dogster". In more complicated scenarios, this metadata could be used for searching trees, or it could be used for alternative custom views of a tree. For example, if the tree on the server was categorised first by subject then by author, I could create a custom view where it was categorised first by author then by subject using the metadata.

The trickiest bit would be the synchronisation I think, which would probably require some quite sophisticated client software rather than being just browser based.

Interested?

I like the ideas,and we could all do with a fun online file system (or atleast I could) I had an idea similia for comunity media reviews.

Your test sit e looks good, Linux/Mozilla Tested OK.

-- DoctorMO --

Yeah, I use it to store stuff online too (I can run different sites off it using the same scripts).

I'm willing to share the source code, and even let people run sites from my server, if people are interested in helping me to develop it. The concept is quite strong - the idea is to create dynamic, standards-compatible sites. One think I've almost got working is having relevant tags generated automatically through article grouping.

The thing that the site is desperately crying out for at the moment is a script to let users log in and save their login as a cookie. Trouble is I'm not sure where to start. Anyone want to help?

have you got access to perl?



gues what I've been up to, an MD5 (one way) encription login, with database and secure (two way this time) encription with page checking. probly very secure.

-- DoctorMO --

not really. it's all php.

all i really need it a function which can be called from other scripts, which, when called, returns the number and display name of the user logged in. plus scripts for logging in (checking password against database) which saves cookie, and for logging out (deleting cookie).

all you need to worry about there is security, any one could packet snif any users conection and get there details, so you have to encript client side, and I have a javascript for the MD5, I never store the username or password on the server, I just compare the encripted garbage. cookies should be no problem in PHP, if it's anything like perl then you normaly have to set them all between the http content header and the second carage return. you might want options for automatic logging in, and you'll probly want your script to know who is calling a particular page. in my database were I keep user information, when I see thair cookie, I populate an array from it. with the array you can then check if they have permitions to use certain things or what there name is. I supose it depends on how you aranged your scripts in the first place, I did mine though a tree like structure with one index script to keep all these resources available.

I just hope the PHP databsing is easyer than the DBI.

-- DoctorMO --

You said you just compare the encrypted password, right? What happens if I use a packet sniffer to capture the MD5 output from somebody's browser and send it to the server?

It's hard to make a system like this truly secure without using encrypted transmission (e.g. SSL).

The system I'm working on for login for my site uses plaintext login over SSL to set a userid cookie which is the only thing ever sent over a non-encrypted protocol. The userid is based on the user's IP address so that sort of a capture won't work at all. The only problem I'm having is hosting. I can't run a local secure server because an SSL certificate costs $200 American. Looks like I'm going to have to ask my local providers.

Also, generally speaking putting things on the client side is bad. If the user can see it, the user can mess with it. Plus there are differences in browser implementations, the user might have JavaScript turned off or not have a JavaScript capable browser, etc..

with the kind of website I'm developing, if people don't have JavaScript enabled browsers then they don't realy need the functionality.

as for the security, I figured that out too, I got a key system inplace and the cookies are encripted again all server side. no one could just pass the information to the server, it has to be the person who called the page.

And SSL, huh, what a way to earn money, handing out 5kb of security information per reqest. it's a joke. and there are questions about it anyway.

-- DoctorMO --

What you're really paying for when you buy an SSL certificate isn't the 5KB of security information, it's the assertion by the certificate issuer that your server is who it says it is. That's not to say I think it's necessarily a good system; I can't afford a $200 certificate for a free website...

niether can I for a small buisness website. it can go and jump, for I think that reasonable security can be achived with out.

-- DoctorMO --