what would you want from your CMS?

ralphuk100

Im on the verge of building a fully featured CMS package. Its going to be a long time, it will be done in my spare time which at the moment does not amount to much! However - I started planning the system and realised I only have my own requirements. What would you or anyone you know like to see in a fully featured CMS? Basically one that can run an entire internet / intranet. It will have the ability to create templates, edit them, content, users, admin etc etc. Im curious as to what things I have not thought of that people want? all suggestions welcome, but please note that money laundering, pimping, or air miles cannot be provided.

drawmack

one thing a cms absolutely needs is the ability for pages to be scripts. In other words I can store text in the database and it'll make it into a page or I can write a script that uses the headers and footers of the rest of the site and plug that into the cms.

ralphuk100

well it will have templates, and the ability to create and edit them. You could edit the header for example. This would probably edit a static page rather than a db entry to reduce processor overhead. I have not figured out how to do it yet, but I want to create a wysiwyg template creator that allows you to specify a page layout with a table. any thoughts on that?

drawmack

well if you're planning on that then I won't use it. Anythat that can be changed from a php form should be stored in the database for security reasons.

What I'm talking about is I'm using your CMS and then I want to have a my links page so everyone on the intranet can store their favorites on the intranet instead of their local machine (this is quite common). I need to be able to write that little script and plug it in through your cms.

ralphuk100

Your post contradicts itself.....

ralphuk100

I completely disagree with the security reasons part of things. For one, I would only allow editing on php files, not txt files. Whether you try to run malicious code into a php file or the db it will be refused. Please explain your security implications. I would either have a) a php file that calls a db record, or b) a php file that contains the page source. Either way the output would be the same. Except slower if everything was called from the db. I am only talking about page templates being stored as php files anyway, content will be handled with the db. But to place an entire page source in the db defeats the whole purpose of cms. You might as well just create a lot of static pages.

Something like a my links page would be a cms module rather than someting an individual user adds I think. But if you did want to add it separately then the page would not go instantly live. Any page containing script would be put into the workflow manager as pending. And if you added your script inside a template it would go into the db, but the actual page would not. Hope that makes sense.

drawmack

in order for php forms to edit files on the server the user that php runs under must have read and write permissions on this direcotry. Since that is the same user as the webseerver this opens a backdoor into the server that can be exploited by a hacker.

drawmack

Originally posted by ralphuk100
Your post contradicts itself.....

no it doesn't the script would not be uploaded from inside the cms it would simply be linked to from inside the cms.

ralphuk100

Well the plan was for these includes that can be edited to be outside the web directory structure, i.e in /cmsinclude/ on the root rather than publically served. So even if a hacker did have read / write on that dir he could only do anything with it through the forms. Which he could do with db entries anyway?

Please ignore the contradicts itself posting, I put that, then decided it did not but hit reply by mistake so it got posted.

ralphuk100

however, saying that - although I had planned to put the includes outside the public dir's this was just standard procedure, I had not considered the security implications that you mentioned so thanks for that. As I said - its going to be a long long process 🙂 More of a personal project really! a Life long one at this rate.

drawmack

Originally posted by ralphuk100
Well the plan was for these includes that can be edited to be outside the web directory structure, i.e in /cmsinclude/ on the root rather than publically served. So even if a hacker did have read / write on that dir he could only do anything with it through the forms. Which he could do with db entries anyway?

With putting them in a folder, if the hacker is not coming in through a web browser (which any hacker worth their salt isn't going to) it will not matter that they are not in the web dir. They can use this read write access to upload a binary that will make them a supper user and then run it. With the db you've got the os protection plus the db protection, more layers on the onion is a good thing. So even if the hacker manages to get a malicious binary into the database they won't be able to execute it.

ralphuk100

Do I have to give the dir read/write access though? Cant I just apply it to the individual files?

Im sure there must be ways to limit what file types are uploadable to a particular dir?

I have worked on many CMS packages commercially, as well as havingb professional Vignette training. Somewhere along the lines there always has to be hard coded templates to avoid slowing the db down to a crawl. I get what you are saying though. And I am taking note. I think the best methodology for this would be to create wireframe templates, just blank table layouts and place everything else (apart from images) into the db. Any thoughts on that?

drawmack

Originally posted by ralphuk100
Do I have to give the dir read/write access though?

If you're going to allow them to create new templates from inside the app then the directory itself needs to be read/write so you can create the new files. You can get around this by using php's ftp functions. I started with an extreme statement to get your attention, it's a bad habbit I know.

Im sure there must be ways to limit what file types are uploadable to a particular dir?

From inside the CMS you can do this. When I talk about hacking I'm not talking about security holes in your CMS. I assume you're intelligent enough to code securly. What I'm talking about is the real hacker who look for vulerabilities in the underlying architecture.

Somewhere along the lines there always has to be hard coded templates to avoid slowing the db down to a crawl.

Right but those don't have to editable from inside the cms.

I get what you are saying though. And I am taking note. I think the best methodology for this would be to create wireframe templates, just blank table layouts and place everything else (apart from images) into the db. Any thoughts on that?

That could work, though I do recommend using css positioning instead of tables. Then you can store the templates and allow the person to modify the css which is stored in the database. If you use css positioning properly then you can completely redesign a site by changing only the css.

Also I usually stick my images right into the database. Just cause it makes life a little easier and the speed trade off isn't that much unless it's a very image heavy site.

ralphuk100

We are going to have to disagree on the images front 🙂 I have no intention now or ever of using any method other than an images table with filename/linked file id/userid and an images directory. I just dont think its good practice to store BLOB's in the DB. But more to the point, if I ever get this finished I will probably put it on client's websites (they have a very simple CMS at the moment) and I have no idea how heavy their traffic will be for new clients and don't want to have to re-engineer the images.

Yes it will be secure - I am writing a login script using password / username hashing (md5) combined with a secret key on the server (Im trying to figure out a way to cycle the secret key). The password will be encrypted before being sent to the server for checking validity using JS and the transmission will be done through the SSL layer. Although any tips on that are welcome.

Thinking about it CSS positioning would be a better bet for template creation, I did not think about that much when typing it. The only thing is. How do I get around the damn CSS footer positioning problem. Im guessing you know what I'm talking about?

Thanks for the input so far.

drawmack

Originally posted by ralphuk100
The password will be encrypted before being sent to the server for checking validity using JS and the transmission will be done through the SSL layer. Although any tips on that are welcome.

If you're encrypting it with js before sending you are not adding any security. The reason is anyone can get that js just by loading the login page. Then they have your algorithm and your key. As for cycling the key on the server, depending on what type of encryption you're using every 90 days should be sufficient. I would say to run tests on the site's traffic (automate them) and then schedule the key exchange at times of low traffic as you'll have to either use a temporary table or pull the site off line to cycle the key.

Thinking about it CSS positioning would be a better bet for template creation, I did not think about that much when typing it. The only thing is. How do I get around the damn CSS footer positioning problem. Im guessing you know what I'm talking about?

actually I'm not sure what you mean. My site (link in sig) is 100% CSS positioning. If you would like to look at how I handle it. I'm guessing that you're refering to ie needing to use height and all other browsers using min_height. I just do browser detection to decide which to print.

drawmack

oh and if you do it with OO programming then you can create two images objects, one that stores in the database and one that stores in a directory. Both have the same methods with the same interfaces then you can just use the one that's appropriate at the time.

ralphuk100

If you're encrypting it with js before sending you are not adding any security.

I am only encrypting the username / password hash client side. Not the server key. Its just javascript to convert plain text entries to md5 before sending them so they cannot be intercepted en route. However, its not really necessary with SSL covering the transmission I dont think. The login page wont have any of this in it, it will just accept the username/password in md5 format rather than converting them.

I was referring to getting a footer at the bottom of the page when it spans 3 columns, or more. Any suggestions on that?

drawmack

Originally posted by ralphuk100
I am only encrypting the username / password hash client side. Not the server key. Its just javascript to convert plain text entries to md5 before sending them so they cannot be intercepted en route. However, its not really necessary with SSL covering the transmission I dont think. The login page wont have any of this in it, it will just accept the username/password in md5 format rather than converting them.

SSL uses RSA encryption, no need for the hash to md5 on the client side. Besides if they intercept the md5 string then they could just retransmit that string they don't need to decrypt it.

I was referring to getting a footer at the bottom of the page when it spans 3 columns, or more. Any suggestions on that?

Hmmm, I've never run into that but if you do up a little example I'll be more the happy to help you brain storm it.

ralphuk100

there is a page on the net somewhere I found that has a kind of solution to the footer problem, I will dig it out and post the link so you can see what i mean graphically.

drawmack

cool thanks, BTW: I just posted a script that creates thumbnails from uploaded images in the code critique section. You might want to check it out. It could help with this.