path or vars

[MadGypsy]

I'm at the point with this cms that I'm building where I am customizing my urls. The possibilities for the types of media that will need to accessed are

article, video, audio, image, file & playlist

the two url types I have decided to choose from are:

type A:

mysite.com/article/{16 character id}

*obviously "article" would be switchable with any of the 6 types and {} would not actually be in the url.

type B:

mysite.com?media=a_{16 character ID}

a would = article and the other prefixes would be (au, v, f, i, pl). As above, there would be no {} in the url.


EDIT type C:

mysite.com?article={16 character id}

I'm sure you get it by now.
___

I'm not sure it really matters but here is a little bit more information: Playlist can be a playlist of anything (except files). I have to write some serious logic here because a mixed-media playlist is going to be interesting to handle. However if the playlist is not mixed it becomes more powerful. Here is the logic:

if all images - convert to slideshow. So, image playlist = slideshow
if all videos - create queue.
if all audio - populate player with all audio
if all articles - include pagination and convert to multi-part article.

no file playlist

however, if it is a mixed media playlist, I will probably have to paginate the entire thing. So, it would be like a multi-part article, each containing a new piece of media. I'm not sure if that is useful in any way, but I see no reason to exclude it's possibility.

Anyway, feel free to help me pick a type and add any other suggestions or comments you may have.

cheers

[Spirit]

Go for the fake path-like structure if you value search engine rankings. Also some idiotic people think it is a great idea to make browsers not display GET variables in the URL anymore.

[MadGypsy]

It depends on what you are "$_GETting". For instance, I have a rank system and the last thing I need is &rank=up (or some such thing) in my path. Actually, I don't $_GET my pagination pages either. The focus is the article/media not the comments section.

I $_GET my $do's - just like this site.

I'll give a lil more time to see (if) how other people vote.

[Spirit]

I am confused what you are doing/what you ask.

Making actions triggered by GET is highly dangerous unless you can control who and what can access them. Any bot (or someone with a website mirror tool) could ruin your data by indexing all your URLs.

[MadGypsy]

right. That's exactly what I'm saying. That's why the only thing I am $_GETting is the media ID (like you tube, I guess).

You understood and answered the questioon.

[Solecord]

When Spirit says GETing, I think he's referring to using the query string like your examples of b and c.

I personally prefer structured URL's... for a web site pertaining news I would do:

Home page: domain.com
News page: domain.com/news
News category page: domain.com/news/category
News story page: domain.com/news/category/quakeone-launched-today

Basically how the forums are set up here...
quakeone.com
quakeone.com/forums
quakeone.com/forums/quake-talk
quakeone.com/forums/quake-talk/chat-o-rama
quakeone.com/forums/quake-talk/chat-o-rama/9606-path-vars.html

IMO, if you can visualize how deep you are on a web site using the URL structure, it makes sense to me. Deleting one segment of the URL allows you to go back and still know where you are on a site. Again, this is just personal preference to me.

For an ecommerce site it may be a bit different. If you look at the big dog Amazon.com, you'll note all of their product pages use the same format for a URL:

amazon.com/Product-Name/dp/part-number

For Quake 1 on CD: amazon.com/Quake-PC/dp/B00080LSOY

Again, I don't know how your CMS is being built, but I would give the ability to categorize content and use the categories in the URL structure. That's just me.

Using your 3 examples though, I would pick A over B and C. I would avoid using the query string for displaying content.

[MadGypsy]

I regard your information with a completely open ear. My one little $_GET syntax couldn't lead to any drama, because:

if(isset($_GET['media']))
{
	extract($_GET);
	$sql = "SELECT media_path FROM media WHERE media_name = '$media';
	// do sql
}

ya see? the only thing that $_GET has access to is the actual media path. Worst case scenario, someone could hotlink a media file, but they actually still can't.

All that being said, I am going to take both of your (agreeing) suggestions and implement them.

__________________________________________________
I was going to make this a separate post, but this is as good a spot as any:

Sometimes I like to put everything together in image format as sort of a morale booster. It often seems like things are going nowhere, so much code that is functional but not visual leads to massive typing, but with no real visual changes, and the feeling that time has stopped.

This image is my current project session with a grand majority of the core of my CMS open. It is already almost as long as a vanilla qc source.



the next two images are the top and bottom (overlapping) of my current new thread progress.




This final image is my current "media center" progress.



The media center is the hardest part (currently). I have ?created? some tricks that allow me to give the feel of a full blown AJAX environment without using (almost) any javascript at all. Actually all javascript does is make that lil load bar on the left move. and spits out a "x files have uploaded" message in real time. I relied heavily on the $_SESSION super global to pass information back and forth quickly between 2 controllers. The result gives the feeling of an app, as you never seem to leave the page. Also, this method allows me to keep "static" page resources alive, saving time on a bunch of reloading something that will never change.

please note, this is absolutely a WIP. I have tons of work to do. The "ugliness" of it is something I can't even consider right now. I've only just begun taking my stylesheet seriously and I am applying a theme to this thing with absolutely no idea as to how I want it to look and no real determination to nail it at this stage.

[Solecord]

if(isset($_GET['media']))
{
	extract($_GET);
	$sql = "SELECT media_path FROM media WHERE media_name = '$media';
	// do sql
}

Just a note - that is not a good method to handle SQL. You should use prepared statements, or sanitize your input. As it is now, if you were to run that SQL query using the standard mysql_query($sql) you're open to SQL injection.

(this is being written in seconds with no deep thought into this so it may be wrong but...)

Let's say someone calls your page like this:

domain.com/page?media=';DELETE FROM media WHERE media_path <> '';
OR
domain.com/page?media=';DROP TABLE media;

your variable would get set to this:

$media = "';DELETE FROM media WHERE media_path <> '';";
OR
$media = "'; DROP TABLE media;";

and all of a sudden your media table would be f*cked!

Always sanitize your variables if you're using GET or POST requests within a query, and always best to use prepared statements:

PHP: Prepared Statements - Manual

[Solecord]

BTW, what editor are you using in that first screenshot?

[MadGypsy]

1) it was just a simple example. I'm not going to say that my SQL is masterful but it's better (more secure) than my example. They cant put that in the url and get anything - unless they can write an sql statement using only 16 alpha-numeric characters. Your injection would result in this

exit ('this page does not exist');

which is my temporary way of handling it, but my permanent way will just be a more elegant version of what it already is.

maybe:

header('location:index.php?msg=you%20are%20a%20fuc king%20moron');

don't forget, I'm the friggin master of parsing strings. If I wanted to I could go nuts and personalize messages based on the $_GET imagine this upon submission.

"Why don't you DROP yourself off of a building and stop wasting your time on my DATABASE"

"I couldn't DROP that TABLE but I was able to ban you. Thanks for playing."


2)notepad++, brah. Is there any other editor? I can't believe I used to type all of this shit in wordpad (lol)

3) I am familiar with prepared statements. I can't remember why I decided not to use them, but I do remember there was a reason and (at least at that time) it was a good one. I use mysqli (-> OOP style)

[MadGypsy]

I could do it another way. I could change the media name to 16 numbers (only) and simply cast $media to an int.

[Solecord]

Re: 2) Notepad++....

for PHP projects, NetBeans IDE FTW!!!

[MadGypsy]

I like netbeans but it is too clunky. I open my project in NP++ and it jumps to life exactly as I left it, instantly. Netbeans is loadalicious. NP++ also makes it very easy to modify the editor.

I took a np++ minimalist portable and converted it to a complete QC editor that even has a multi-option compile menu, in like 2 hours. All I had to do was edit an XML file for syntax hilighting and create a bat that I assigned as a keyboard shortcut (for compiling). Netbeans is not that clean and simple.

I'm running my entire production environment from a usb card. I could dump the entire contents of the card on another card and then edit the drive letter, my computer wouldn't know the difference. I don't really want to mess with a portable java platform just to have the same thing with netbeans

Xampp portable (latest)
Notepad++ portable
Firefox portable w/ FF 2nd profile
Flash Develop portable with latest FLEX sdk

that's my entire environment...lol

[MadGypsy]

domain.com/page?media=';DELETE FROM media WHERE media_path <> '';

I realized something yesterday about the above situation that you posed. My site does 2 things that I personally have not seen done elsewhere (together).

1) there are 5 static permission sets and a user inherits the permissions of his level and all of those below him. This means (for instance) Level 3 doesn't even have site read access, or level 2 or 1 for that matter. Site read is a level 0 permission. Level 3 inherits the permissions of level 0, because 3 >= 0.

2) Everything is done using the least common denominator. Considering the GET $media is just an id to match a row in the database and return some values, site read is the only permission necessary. This means even if you are the site Owner you cannot pass that sql injection into the url. You do not have the permission to DELETE in that query, no matter who you are.

oh and 3)
My read access user doesn't even have database-wide read privileges, as a matter of fact, it doesn't even have table wide read permissions. It has specifically defined column read privileges. So site read technically has USAGE permissions on every table.

You gotta admit... I have it so locked up you can't even hack yourself. This is one of the things that seriously held this project up. I started this project by writing an entire database install script, based on a model that I was daydreaming about. When I started using the "least necessary permission" method, it forced me to rethink the entire install script, database structure and who can really do what to what.

My system is so locked up that a guest didn't have the permissions to sign-up (LOL!), because that would require writing and a guest can't write to the database. if they are sending data from the registration form and session time has not expired and all data passes regex validation AND stripslashes (as well as being cast to an int in some cases)...lol their level goes up to 1 right before committing the data and is dropped right back to 0 the line after calling the query. In this case you are using a site write permission that mirrors the site read with write privileges. INSERT is it's only permission and it's a heavily restricted permission, because it is essentially user-level write. There's a lot that I fdon't want a user writing to.

oh shit .. 4)
it's not "media" (as in the table) its D5R4Z_media.. so to speak. More commonly known as '.$this->prefix.'media in my script.

[MadGypsy]

I got the path version working but I have to go make adjustments to all oof my HTML where paths are placed. Something as simple as my stylesheet is not being found because as far as html is concerned I'm an entire directory up from where I am supposed to be.

ex
styles/stylesheet
becomes
article/styles/stylesheet when I use a path

no big deal. I took the 15 seconds it took me to customize my host and httpd-vhost.conf to reflect real world URLS

ie..no more:

localhost/sitephyre/index.php

My server understands sitephyre.com now so this whole path style redirect thing should be a breeze to correct globally.

I've officially decided that prepared statements aren't going to happen anytime soon. My model basically treats mysqli like prepared statements and my permission system doesn't let you do jack shit. For me to go redo that level would be a gigantic step backwards for very little (possibly no) gain.

Considering my method is almost a faux prepared statement system, I think moving forward to the very end of completion would be wiser, giving me the opportunity to look at the entire sql as a whole and make a decision as to whether or not to change it then.