So Play We All News

Ledger

Net Profit: $158.12

Hourly Earnings: $3.24

$19.12 - 2011-09-06 - Rule Violation Payment (Peter)
$19.92 - 2011-08-31 - Rule Violation Payment (Luke)
$28.83 - 2011-08-30 - Rule Violation Payment (Peter)
$10.00 - 2011-08-14 - Rule Violation Payment (Luke)
$30.00 - 2011-08-05 - Rule Violation Payment (Peter)
$10.00 - 2011-07-18 - Rule Violation Payment (Peter)
$10.20 - 2011-07-16 - Rule Violation Payment (Luke)
$20.30 - 2011-07-14 - Rule Violation Payment (Luke)
$29.91 - 2011-06-11 - Rule Violation Payment (Luke)
-$10.16 - 2011-05-18 - Domain Name

Class Session

published by JGadrow on Sat, 07/02/2011 - 18:44

Some of you might see the title of this post and think maybe I'm holding a class... Nope, I implemented custom session handling this week. Again, we had a minimum of 2 hours this week so I spent the maximum 6 hours making the progress that I had wanted to make last week! Before I get to that, I'm going to ramble a bit about what the rest of the week brought.

Work; Devourer Of Hours

I ended up missing work last Friday because I wasn't feeling particularly well. Unfortunately, I had a project at work that I had originally estimated at around 80 hours of labor required to complete it. I was given less than 50. So, of course, I couldn't afford to have missed last Friday. So, I opted to work extra hours each day until the hours were made up. I also had a couple of hours for one of my PT clients come up this week (which reminds me, I still need to generate those invoices...). So, that's why you didn't get more fluffy stuff to keep you entertained this week.

The Fluffy Stuff

Each week, from here on out, I'm going to let you know what "bonus" content was added to the site... just in case you missed it. This week, I didn't have much time to do anything. But, I've mentioned my business plan for Allabrilyn a couple times in the past and wanted to get it online for all to see (and critique). It was, largely, a copy / paste from an email I had previously sent to Indie Fund. That's all for this week. It really breaks down the feature set that I have planned for the game so I advise you to give it a look even if you're not really interested in marketability.

Progress Report

This week, I started from my only remaining TODO tasks, both of which involved the CommandRouter. I finalized the implementation of the CommandRouter for this week and added three handlers that process the core system Events. Harkins made a comment a while back about "python poisoning" because of my Event names. The reasoning for this is that Event names are generic and when the system becomes extendable, you'll be able (encouraged even) to define your own. However, Event names beginning with __ will be considered reserved for the Framework's use. And the trailing two __... well, it just looks unbalanced if you just have the front ones!

The Events:

__INITIALIZE__ - This event signifies that the system should perform any routines necessary before commands are processed. For instance, the Session handler triggers on this Event and attaches itself to the Application. More on the Session handler later.
__USER_COMMAND__ - This event, basically, breaks down the URI into an array. Most extensions will not trigger off of this event, but will, in fact, be loaded and processed by the Page handler.
__RENDER__ - This event signifies that the Application wants to render the content for return to the user-agent. I'm proceeding in the intent that this could mean an HTML page, an AJAX call, etc.. Not every request is assumed to be wanting a full HTML page.

The Application isn't terribly concerned with a whole lot. It's just in charge of storing important stuff and getting the ball rolling. The CommandRouter does the heavy lifting of deciding what classes to load and what class methods need to be called. It does this by querying a table (called event_registry) that maps a class and method (method can be null if the class just needs to be instantiated) to an event. There is also a seq column that affects which rows are processed first. It prefers to call handlers in this order:

Highest seq value
Alphabetically first class name
Alphabetically first method name

As far as the Handlers are concerned, I stubbed them out (you can see that they're, indeed, being called if you view the live site) at first and went back and began implementing them in order. I managed to complete the Session handler before my time was up for the day.

Sessions

For anyone not familiar with them, PHP Sessions are just a way of keeping track of stuff between page loads. Ever wonder how a website knows who you are even after you browse away or what-not? That's how. So, obvously, implementing Session handling is one of the steps I needed to accomplish to get back to a point that you could register, login, etc. again. Right now, the handling is basic. Just a typical intercept of the functionality to make it work with the database instead of flat files.

Why would I want to override the default? Well, for one, we're already going to require an open database anyways so it'd be inefficient to open a file and read it too. Also, if the game takes off to the point that I need multiple servers running to support it, storing sessions in the database is one way to make sure it doesn't take me forever to get up and running with a bigger infrastructure. Think about it, if you have 3 servers, that uses a load balancer to pass requests off round-robin style (yes, there's other ways, but we're just using this for argument's sake) there's no guarantee that you'll be on the same server for each page load in a user's session.

For example, say we have 3 servers and they are setup round-robin. This means that the first HTTP request received by the load balancer goes to server 1, the second request to server 2, the third request to server 3, and the forth request goes back to server 1. It keeps up that pattern, continuously. The point of such a system is because so many users are accessing at the same time, it would destroy the server if they were all accessing the same one at the same time. So, if you're using flat-file storage for your sessions, on Sally's first access, she was routed to server 2. However, when Sally logs in (which causes a new page request), her request was sent to server 1 (a couple people accessed in between Sally's attempts)... Sally's session data isn't on server 3 though! Now you've just lost Sally's data... and Sally is sad.

Anyways, we're protected from that little annoyance though. However, another potential problem with sessions (and the reason that I always explicitly log off of any website) is called "session fixation." Basically, in order to keep track of you, a website sets a cookie on your browser with a bunch of non-sensical letters, numbers, etc. in it. This is your "key" to give back to the server and tells it who you are. The problem is, there's several nasty ways to steal that key from you and then to make your computer hand it back to the server. Basically, if Sally clicks on a bogus URL created by Richard (we'll just call him Dick... cause that's what he is... a Dick), Dick now has Sally's key and can feel free to get into Sally's account and do whatever he feels like doing. Sally is sad... again. Sure, it was Sally's own stupidity, but we should have known that Sally wasn't the brightest crayon in the box and tried our best to help protect her!

How do we do this? We try to give Dick a very short window of opportunity to use Sally's key. The first thing that we do is every time Sally gives us her key, we give her a new key. The old key no longer works. Now Dick has to make sure he access the site before Sally does again, or he's screwed. Now, of course, Sally can click on Dick's bogus link and then go away from her computer for a long time (maybe she was kidnapped by a stranger promising her candy if she jumps in his van... but then she probably has bigger worries). This means we don't have the opportunity to change Sally's key before Dick tries to use it and he'd be able to do as he pleases... again. So, what we need to do is define a short, yet reasonable, period in which the old key is usable. Maybe 15 minutes or so. Ever come back to your computer after a long time and the site "forgets" who you are? Yeah, it's trying to protect you from Dick. Now, Dick has to get Sally's key, Sally can't use the site again before Dick, and Dick has to use the key he stole less than 15 minutes after the last time Sally loaded a page on the site. That's a pretty tall order. Not impossible, but nothing involving the internet is 100% secure. We've gone to reasonable lengths to protect Sally from her own stupidity.

In case Sally still manages to get screwed over, logging in will generate a new key for Sally again. Meaning Dick has to fool Sally all over again. That's why any crucial operations that are performed (such as changing the user's password) should require the user to enter their current password. Just because Dick stole Sally's key and tricked the site into letting him in does not mean he has Sally's password. If Dick were clever, he could go and change Sally's password so he could login any time he wanted... but by asking for her password before allowing the change, Dick is foiled again.

Anyways, that's all that for this week. Next week, I'm either going to work on the Form handler (which loads on __INITIALIZE__ after the Session handler does) or start creating the User stuff. We shall see.

Comments

Coach Outlet Online

Fri, 12/09/2011 - 20:08

Main menu

You are here

Search form