Comments

This prevents adding a site sending the header from being included in an iframe which in turn prevents click hijacking. At this point iframes are pretty rare as a standard expected usage case and so defaulting to not allowing them seems to be a more secure way to go. It could always be enabled if needed in a particular case.

This comment has been minimized.

Yeah I'm not for a config option. It should just be default and override if needed. To be more clear, by setting sameorigin it can still be included in an iframe from the same domain so it's only limiting third party inclusion.

This comment has been minimized.

Yeah. I think it's good by default, I'm just thinking that it should be well documented where to go in the shell to modify that behavior. Whether a config, or you have to do something like Request::setHeader(...)?
—
Sent from Mailbox for iPhone

Yeah I'm not for a config option. It should just be default and override if needed. To be more clear, by setting sameorigin it can still be included in an iframe from the same domain so it's only limiting third party inclusion.
On Jun 24, 2013, at 12:28 AM, Taylor Otwell notifications@github.com wrote:

Is this functionality documented ?

This comment has been minimized.

Is there any way to remove the X-Frame-Options header for a single route? During an after filter the X-Frame-Options header is not yet set and therefore can't be removed.
As you can see, the header is set, after the application handles the request.

Hmm... It wouldn't be possible to completely remove the header then, though? Just override it...

This comment has been minimized.

Correct, but it can only be used before the app handles the request i.e. in the start file.
I'm looking to remove the header for a single route i.e. in a filter or simular.
As you said, checking if the header is already set, would be fairly easy, but that's not how x-frame-options works. To grant iframe access for everyone the header should not be present at all.

However for my usecase I found a work around which acctually makes my app more secure.

My Conclusion:
Check if the header has already been set in the FrameGuard. Change the FrameGuard whem a suitable solution is found.

This comment has been minimized.

After wasting a day to find the issue I had is here (litterally but finding the problem point in the code), this FrameGuard is not helping at all, since all Facebook app developers will have blank apps. FrameGuard is executed somewhere in the actual sending of response, where the user has no control. There is no option for overriding it, tried in App::after, but instead of overriding FrameGuard value, it overrides mine.

I suggest to remove it or make it configurable and mention it in the docs. Whole day searching in Google for hint and there were 0 useful topics and almost made me drop laravel for Facebook applications, where I find laravel very nice.

It seems to work with forget middleware, ok this is solution, but we have to put it in somewhere in the docs, how I could relate as new user empty Facebook page with FrameGruard, especially with forgetMiddleware? Isn't it reversed logic, I expect to add/enable Middleware, not to forget it? I expect to write code, not to disable parts of it (talking for extra functionality which optimizes my code to run)? Its for me like:

...which is not constructive logic, but kind of opposite. I am trying to look from another view point. It is cool to have many/all things loaded, but there is also performance cost. I am wondering how many points like that exist currently in the version I have? Do I need them all?

An idea is to move such optional executable functionality as an extension or something which is expected to be used only when needed (I don't instantiate FrameGuard, neither tell it what to do - it is self operating unit) or at least leave extra units disabled by default.

However, the most important thing is to document that and other "issues" like it - to make laravel more accessible and easier to use. I can try to describe it somewhere.

Correct me if I am wrong. I may also fork and apply solution to this issue after that.

It seems to work with forget middleware, ok this is solution, but we have to put it in somewhere in the docs, how I could relate as new user empty Facebook page with FrameGruard, especially with forgetMiddleware? Isn't it reversed logic, I expect to add/enable Middleware, not to forget it? I expect to write code, not to disable parts of it (talking for extra functionality which optimizes my code to run)? Its for me like:

This comment has been minimized.

Is there no way to apply this override on a view by view basis? It flat out kills all Facebook page apps so has to be disabled to avoid blank pages. However, I assume it is useful generally so it would be good to keep it elsewhere.

This comment has been minimized.

I dont know how many people affects, but surely those who develop cross-domain apps. It is useful, but the lack of control make it pain in the ass. If I can turn it off/on or set the value of DENY|SAMEORIGIN|ALLOW-FROM it will become shining diamond no matter if it is enabled by default (should be mentioned somewhere in the docs).

After Googling for a while I ended up here from a couple StackOverflow questions. It may be less than 1% but there's a handful of us looking for a proper solution. Importantly, I think most developers want FrameGuard on most of the time. In my case I just need to turn it off for a single controller method that acts like the Evernote Web Clipper - accessible from any page.

This comment has been minimized.

This has wasted me a lot of time also.
Seriously, servers have cross domain protection.
Apache htaccess, etc. Why inject it deep in the core of a framework is beyond me. Where is all the help for this.
Laravel forum has no results for "Header Access-Control-Allow-Origin", weird.

This comment has been minimized.

To all that feel this had wasted their time, how about getting involved with any proposal/suggestion on Github so before any changes happen your concern has been noted.

Just look at the the discussion above, it took @taylorotwell 4 months to finally make this changes, within those 4 months there no objection. Why? Because does who were involve (responding to it) doesn't have any objection.