- added "secure" parameter to avoid boilerplate "if https && https != 'off'"
- added "accept" parameter containing request's HTTP_ACCEPT value if any
- Changed IP to always be REMOTE_ADDR, as this is the only "real" ip of the request.
- Added 'proxy' parameter containing any proxy-forwarded IP
- Changed getIpAddress to getProxyIpAddress
- renamed $vars to $forwarded to be a bit more explicit
- Removed REMOTE_ADDR from proxy forwarded addresses to detect
- change explode() to sscanf, will explain this later.
- added flags to the filter_var, will also explain later
- added getMethodOverride function to detect request method overrides
I did some research because I was wondering why it would be necessary to check
for a comma, and apparently some proxies do send a comma separated list of IP
addresses, with the originating client IP as the first one. It had a feeling
that instead of using explode() where the first value would always be returned,
there must be another way to get the first value of a token-delimited string,
or just the whole string if there was no token, and I bumped in to my old
friend sscanf. So the loop is now 3 levels.
As far as the flags, see: http://php.net/manual/en/filter.filters.flags.php
These ensure that any IP detected is not a useless IP behind a remote NAT.
For example, a corporate proxy might send HTTP_X_FORWARDED_FOR using the
internal IP of the user, but the only useful IP in this case is that of
the proxy, which PHP gets as REMOTE_ADDR.
If you find any of these changes acceptable but don't want to merge them
all, do feel free to implement whichever you like.
I was thinking of adding a getRequestMethod() function to check for
`$_SERVER['HTTP_X_HTTP_METHOD_OVERRIDE']` or `$_POST['_method']`
to allow clients to negotiate PUT/DELETE requests,
but personally I am indifferent to these, as I never use
methods beyond GET and POST (I'm not very RESTful I guess),
and it's not really my place to be writing an implementation
of either. Other frameworks seem to just overwrite the method
parameter so that it appears to be the overridden one.
Allows users to pass an instance of a class in to the Flight routes function, and invoke methods on it in a non-static context.
Example usage:
$obj = new Obj();
Flight::route('/myMethod', array($obj,'myMethod'));
The previous render method allowed you to render a template
directly into a layout. This however only allowed one template
to be used per layout. The new method instead stores the template
results as a view variable, which the layout can reference.
Also expanded documentation on views.
Added a has() method to the view to check if a variable is set.