Category "Requests and Input" tricks

If you are running Laravel 4 and behind a load balancer or a reverse proxy, some HTTPS functions like ‘Request::secure()’ and ‘Request::isSecure()’ will return false. If we add the current IP which belongs to the proxy/load balancer to the setTrustedProxies then the Request class will honour the ‘X-Forwarded-Proto’ and other ‘X-Forwarded’ headers and the mentioned functions would work fine. Note: THIS METHOD CANNOT BE TRUSTED unless ALL requests go through a proxy YOU control.

If you are running Laravel 4 behind Cloudflare over HTTPS some functions like ‘Request::secure()’ and ‘Request::isSecure()’ will return false. By using the setTrustedProxies method of the Request facade we can add the Cloudflare IP ranges to trust, thus the Request class will honor the ‘X-Forwarded-Proto’ and other ‘X-Forwarded’ headers.

I use this to always know in my controllers if the current action is shown through a Facebook tab iframe. Upon the first request this checks if there is a "signed_request" variable posted to the page. Then $fb_state is set to true and shared with all views. The problem is that on navigating to the next page within your app this variable is lost and you don't know if this is shown through facebook. Due to the FB page proxy you can't use sessions to remember this for the next request either. I solve this problem with adding "signed_request" as a parameter (i.e. "&signed_request=123ljshgljsdhflsdhfl") to every link and form when $fb_state == true. Of course you could also pass any other variable if you don't need the actual signed_request data.

When showing a website through a Facebook Page tab validation errors are not displayed, because Facebook "forgets" the sessions due to the page proxy. One problem with this is that session data is destroyed / forgotten on each request going through that proxy. This applies to Redirect::back()->withErrors($validator) for showing the form with validation errors because sessions are used . To avoid this simply fiddle the error data together and pass it directly to the respective action that handles the input form. One thing to mention is that calling other controller actions directly of course does not affect the route. Let's say editing happens at "/edit" and the "registration complete" message is shown at "/complete". Calling the action within the controller the form with errors is now shown at "/complete" whereas "/edit" would be shown if you redirected back (Line 22). I personally don't really care too much about this since the "real" web address is not shown in the FB page tab anyway due to the page proxy. Looking forward to hearing your opinions on this. Maybe there is even a better way.

By this line adding to the app/routes.php file, you can apply 'csrf' filter to all routes

Whoops, looks like something went wrong.

In case you want to access Route parameters outside controller, you can access current Route object and extract parameters from there.

This filter will prevent the route from having sessions enabled. Very useful for API calls and when you don't want sessions starting. Blog Post: http://dor.ky/laravel-prevent-sessions-for-routes-via-a-filter/

On many occasions, I use the subdomain to generate dynamic routes and a custom user experience. The current Laravel subdomain filter, requires a lot of extra work when generating routes. Each time you generate a route, using the laravel route() helper, you have to pass the subdomain as the first parameter. This provides an alternative method without having to pass the subdomain to route(). https://github.com/laravel/laravel/issues/2515 for additional follow-up