Sitephyre WIP thread

[MadGypsy]

Right now I am focused on getting the actual features complete. For me to go back even in the very end and make my passwords more secure is:

a doddle

I mean, we are literally talking about 2 very small spots of code - sign up and sign in, and whatever I do in the sign-up spot just needs to be done "backwards" in the sign in spot.

When the time comes for me to be concerned with this, I will study encryption to death and probably go way overboard (as usual). Right now, password encryption is the least of my worries.

The web works by refreshing everything all the time. I have a portion of my CMS that I don't want to refresh, well, ever. I want it to run like an app as opposed to a web page. That doesn't sound like a big deal until I add in this other stipulation - it has to work without AJAX requests.

Why? you may ask. The answer is simple. I do not build programs that can break. This means that the only things I can ever be guaranteed will be supported are HTML and PHP. I can't even be guaranteed that someone will have CSS on in their browser.

This means that everything has to be considered from the perspective of having nothing to work with, yet making everything work. I then build on top of that foundation with the bells and whistles.

So, will I use AJAX for my "app" page? Sure, I just can't rely on that to be what makes the page work, cause all it takes is someone to have javascript turned off and it wont work.

That being said, how do I intend to fake AJAX with nothing but html and php? The short answer is - I don't know (which is a lie to stop you from asking me all these questions I'm pretending you asked). The long answer is - too long.

[MadGypsy]

Actually, I'm going to sleep in 20 minutes and that's how long it will take me to explain this. For those of you that don't know anything about any of this, I will get you up to speed.

AJAX stands for Asynchronous Javascript and XML. It's purpose is to primarily retrieve information without leaving the page. Basically, you make an AJAX request to a remote PHP file, the php runs and returns whatever data you told it to to the AJAX request and with a request handler you can then spit that info onto the page without leaving it. There are other things you can do with AJAX requests but I find this is the most common and it is exactly the functionality that I need to fake.

Now let me explain what my page actually does and I will follow it up with my "fake an AJAX request" solution.

My media center is "one" page. On that page (via tabs) I need to be able to have:

1) edit basic info - lets say you upload an image, this is where you would describe it, add a title, tags, etc
2) video editor - this is where you will be able to take "screenshots" that will act as the thumbs for your video as well as some other simple video related things (like annotations)
3) playlist editor - this is exactly what it says create/add/delete from/to playlists

you should be able to toggle between any of those without leaving the page. If you know how to program for the web, You are already thinking iframe - bare with me, it isn't that simple.

Now on the right of the page is your entire library (paginated and tabbed by type). You should be able to click ANY element of your library and it:

1) automatically opens in the currently active editor
2) knows that it does not belong in an editor and adjusts - imagine video editor is active and you click an image. Those don't go together and I hate telling the user:

ERROR 500: I am too lazy to make this work better for you

I have (hopefully) brought those that don't understand web programming up to speed, as-well-as brought everyone up to speed on the current challenge. Now I will explain the solution.

First of all, an iframe is correct. There is no other non-AJAX way to switch between these editors without leaving the page. So, the editors reside in an iframe. However, this still leaves the library which is not in the iframe and how do I

a) determine the active editor
b) tell the editor to open the correct piece of media
c) determine if that media is compatible

Let's start with a. The trick is a remote php file that delegates what editor will be shown. For instance, instead of targeting the iframe with video_editor.php. I target the iframe with remote_delegate.php?e=video_editor. This would happen when you click the tab that would bring up that editor. remote-delegate.php sets a bunch of session vars if isset($_GET['e']) resolves to true.

That solves 1/3 of the problem. Now we know what the active editor is, but our library was created before that decision was made, so how do I make a link that was already made, understand that it needs to go to a certain editor?

The answer is actually pretty simple. The answer is remote_delegate.php. But this time we set a new $_GET remote_delegate.php?m={MEDIA NAME}. WE target the iframe yet again with remote_delegate.php but this time we are GETTING instead of SETTING.

if isset($_GET['m']) resolves to true, then the databse is retapped for the info corresponding to that piece of media and it is injected into a list of all open media. The active editor is then refreshed with the new open media list and your library selection becomes the active list selection.

Voila' absolutely fake AJAX requests that do not utilize javascript at all.

Edit: I forgot about the library element/compatibility part, this is super easy. I will explain it in example code

if($_SESSION['active_editor'] == 'video' && $extension != 'flv')
{ 
//switch to a compatible editor
}

That is rudimentary. Technically it would be an array of extensions (cause 'flv' isn't the only supported one) and it would look more like this

$exts = array('flv','mp4','etc');
if($_SESSION['active_editor'] == 'video' && !in_array($extension, $exts))
{
//switch to a compatible editor
}

[MadGypsy]

solved

$hashToStoreInDb = password_hash($password, PASSWORD_BCRYPT, ["cost" => 11]);
$isPasswordCorrect = password_verify($password, $existingHashFromDb);

That cost will actually double the milliseconds from (default) 10 to 20. Making brute force attacks painfully slow. Add to that a: "you have 3 tries to get your password right" function and now you have all but eliminated a brute force attack possibility.

The end.

also: I already had a "speedy session" function that doesn't allow you to do anything that would be measured in milliseconds. Brute force attacks were already handled in that regard.