Refused to display 'https://mytestwebsite.com/?wa=wsignoutcleanup1.0' in a frame because it set 'X-Frame-Options' to 'DENY' - asp.net-mvc-2

I am using ADFS 2.0 as authentication process for the application which is developed using asp.net mvc2 and SQL Server 2012. In order to resolve the issue: Clickjacking (aka Cross-Site Framing or XSF), we have set the X-Frame-Options with value DENY in the web.config file.
Steps to reproduce:
1. Logged into the application using valid credentials using Chrome browser.
2. System displayed me the application landing page.
3. Clicked F12 to open the Developer Tools options.
4. Now clicked on Signout option and navigated to the Console window.
5. System displayed the ADFS Signout page, but still I am getting an error in the Console window as mentioned below:
Refused to display 'https://mytestwebsite.com/?wa=wsignoutcleanup1.0' in a frame because it set 'X-Frame-Options' to 'DENY'.
On checking the ViewSource of the ADFS Sognout page I came to see the following:
<iframe class="Test" src="https://mytestwebsite.com/?wa=wsignoutcleanup1.0">
</iframe>
Can anyone suggest me the best possible ways to resolve the above issue?

One option is to do nothing. The important part of the sign-out cleanup is to remove the authentication cookie for mytestwebsite.com which still gets done, because the http header is still processed, even if the resulting iframe content is not displayed.
Allowing the iframe content to render is only important if:
Your web application performs further down-stream signout cleanup. I.e. it contains its own iframe tags to signout other applications, or
Your STS uses <img> tags instead of iframes for sign-out cleanup, and you want the green tick image that WIF returns to appear, or
You really, really don't want that harmless error message appearing in your browser console.
If it really is necessary, you can add x-frame-options DENY to all responses except WS-federation signout cleanup programmatically.
For an ASP.NET MVC application, you can use (in Global.asax.cs):
public override void Init()
{
base.Init();
FederatedAuthentication.WSFederationAuthenticationModule.SigningOut += this.WSFederationAuthenticationModuleOnSigningOut;
}
protected void Application_BeginRequest(object sender, EventArgs e)
{
Response.Headers["X-Frame-Options"] = "DENY";
}
private void WSFederationAuthenticationModuleOnSigningOut(object sender, SigningOutEventArgs args)
{
if (args.IsIPInitiated)
{
Response.Headers.Remove("X-Frame-Options");
}
}

Related

Wicket 6 PageParameters empty on Chrome and Opera

I have migrated my web application from Wicket 1.4 up to 6.21.
Everything is working fine on Firefox, but on other browsers (tested on Chrome and Opera) on some pages PageParameters are empty.
I checked POST requests and looks the same on each of mentioned browsers. Addresses on each browser are also the same and containing param I want to use.
My constructor:
public MyPage(PageParameters params) {
super(params);
id = params.get(ID_PARAM).toInteger();
// do stuff;
}
causes (of course):
java.lang.NumberFormatException: null
My knowledge about Wicket is rather limited, but app on Firefox is really working fine, so I want to run it on Chrome also.
Any answers or even advice what should I check are very welcome.
Of course I can provide some additional details and code.
EDIT:
Here is screenshot of POST on Chrome (on server PageParameters are empty):
While debugging I encounter really strange behavior. On MyPage there is AcceptButton which redirects to AnotherPage.
Using Firefox clicking AcceptButton results entering AcceptButton#onSubmit method, which is calling setResponsePage(AnotherPage, params).
Using Chrome clicking AcceptButton results entering MyPage() constructor, without entering AcceptButton#onSubmit nor AcceptButton#onError, so somehow it tries reload MyPage.
I have no idea why Firefox works but in the attached image we can see that this is an Ajax request, so it should not go to MyPage constructor at all.
The Ajax request is targeted against AcceptButton (an AjaxButton, I guess) so the post parameters could be read in AcceptButton#onSubmit(AjaxRequestTarget, Form) with getRequest().getPostParameters().
Maybe you redirect to MyPage with setResponsePage() or something like this but the Ajax request parameter(s) will not be automatically forwarded to the page's PageParameters in this case.

how to redirect/map to externalregistration page from AuthenticateExternalAsync to angular page

I am using external providers to login to my web app. (for example Google). In my custom userservice I get to AuthenticateExternalAsync and from there I want (if need to) redirect to Angular page.
public override Task AuthenticateExternalAsync(ExternalAuthenticationContext context)
{
...
...
context.AuthenticateResult = new AuthenticateResult("~/externalregistration", user.Subject, name, identityProvider: user.Provider);
return Task.FromResult(0);
}
i have html page
at https://localhost:44300/Content/app/externalregistration.html
How do I map externalregistration to this page?
At the moment I get an error
https://localhost:44300/identity/externalregistration#
HTTP Error 404.0 - Not Found
thank you
Mark
The page for the partial login has to be with IdentityServer - see that it's looking for it at /identity/ and not /Content/app/.
If from your user service you issue a partial login, then that web page is entirely up to you to serve up from the server. If that partial login page needs to know the identity of the user, then it needs to be hosted in the same path as IdentityServer so the partial login cookie can be read on the server. If you then want that page to be a SPA, then you'd have to have some server side code issue something into the browser for your SPA to know the identity of the user. If you want that page to be a SPA and make Ajax calls back to the server, you need to include some XSRF protection.
All in all, custom partial pages are easiest implemented as standard server-rendered MVC pages.

How can I reload my page to redirect to an URI Fragment in VAADIN?

In my Vaadin webapp I have a tipical architecture with login. In some cases, the user can access directly to some resources using Vaadin URI Fragments (http://example.com/#fragment).
When a user tryes to access some resource, If the user has logged in, I take from the URL the #FRAGMENT and I bring him to it.
But if the user has no logged in, when he logs in I used to bring him to the main page using
getPage().open("/", "_self");
but since if I add an URI Fragment, the getPage().open(...) does not work.
Is there any way to redirect the user to a correct URL (URL with UriFragment in my case) from code?
Note that there is a fundamental difference in how navigation is handled in traditional web applications versus single-page applications as implemented with Vaadin. In traditional web applications you navigate through the app by making full HTTP GET-Requests on some path (such as www.example.com/myapp/home). On each such request, a full page reload is performed. You can't do that with Vaadin, as a full page reload means reloading the Vaadin widget set and rebuilding the page layout from the ground up. Therefore, single-page applications typically use the URI fragment for navigation purposes. Changes to this fragment are solely handled by the client-side JavaScript code. There will be no GET-Request induced by the browser when the URI fragment is changed.
That's why the approach you described doesn't work for you. Using Page.open(...) will open a web page through a HTTP GET-Request resulting in a complete reload of your Vaadin application.
The solution for your problem is to solely handle all navigation (including state-dependent redirects) through the Page object's URI fragment handling methods (or through the [Navigator][1] component). Redirecting in Vaadin can be achieved by programmatically setting the URI fragment with Page#setUriFragment() or Navigator#navigateTo() and having your URI handling code (or Navigator) take care of the rest. Only then it is assured that your users stay on the same page even when they are redirected to a login form or to some other place after logging in.
I would like to add to Roland's answer and share how I solved this.
My UI:
#Override
protected void init(VaadinRequest request) {
setSizeFull();
setContent(masterView);
getPage().addUriFragmentChangedListener(event -> present(event.getUriFragment()));
present(getPage().getUriFragment());
}
The masterView is just a CustomComponent that has a content section. When the menu is clicked, I simply setContent to the masterView's content section. Swapping out the middle, basically.
present method:
private void present(String fragment) {
masterView.setContent(getComponentFromFragment(fragment));
}
Finally:
private Component getComponentFromFragment(String fragment) {
if (fragment.equals(someOtherView.NAME))
return someOtherView;
return null; // null clears it out as in the welcome page
}
The important part is the present in the init. When the UI renders for the first time and fires the init, it goes ahead and grabs whatever the URI fragment is in the browser and presents that as well.
Works great.
Maybe this can work:
UI.getCurrent().getPage().executeJavaScript("window.location.href = 'http://google.com'");

IE9 Error SEC7111: HTTPS security is compromised after redirect (plus "only secure content" message)

I love it when something is working in other browsers and then ya fire up IE and it all goes poof.
I'm getting the following error:
SEC7111: HTTPS security is compromised by http://www.example.com/myappname/?rctp=[an FB user id]
Here's the workflow:
User goes to canvas app on Facebook. Makes choices on form, form submission goes to app's URL on my domain where quick database work is done and redirects back to the app with user id added as a GET variable, which is used to trigger a user-generated request in Request 2.0 fashion.
Works fine in Firefox. In IE9, I get the "only secure content" error message. IE9 F12 debugger console shows the above "SEC7111: HTTPS security is compromised by http..." message.
Not sure why it's showing "http://www.example.com/myappname" as the url it's redirecting from is "https://www.example.com/myappname"
Again... works fine in Firefox. As per some of the other Q's I've seen here, I tried adding FB._https = (window.location.protocol == "https:"); and FB._https = true to the JavaScript but to no avail.
UPDATE: Ok, removing the GET variable clears up the problem. But I NEED to pass that variable. Is there another way to do it?

FB.getLoginStatus not calling its callback

The title really says it all. Under some (undetermined) conditions FB.getLoginStatus() just stops working and won't invoke the callback I gave it. The only interesting clues I've found are
FB.Auth._loadState is stuck on "loading" -- whatever is supposed to make it click over to "loaded" isn't happening
slight delays like putting in alert() calls tend to make it start working
Any hints at all about even how to investigate this welcome.
This usually happens for me when I am running the page under a different domain from what has been registered in Facebook. Typically this is when I am developing locally.
If you are running locally, you'll have to set up a local web server and then modify your hosts file to point the the registered domain to 127.0.0.1 in order to test on your local machine. Don forget to remove that line from the hosts file when you want to test it on the server.
According to:
https://developers.facebook.com/bugs/240058389381072
You cannot put your application under sandbox mode, or else it won't work. Go into your app settings, advanced, and switch it. This stumped me for a couple hours until I happened upon the bug report.
I had similar problem with FB API. It turned out, that my Facebook App was misconfigured. Please make sure that this is not the case for you. My problem was that my "Site URL" param in FB application was pointing to https, but I was using http protocol for development. Any call against FB api after FB.init was not calling my callback functions. So the first thing to do should be to double check App config.
Now, if some reason you depend on FB api but you wish to have a fallback option in case it;s inoperative - workaround with timer should be ok for you. Just set up a timer and disable it if FB Api gives you proper response. If not - fallback to some custom function which will perform some additional logic.
function callFbApi() {
var timeoutHandler = setTimeout(function() { requestFailed(); }, 1000);
function requestFailed() {
// When this happens, it means that FB API was unresponsive
doSomeFallbackWork();
alert('hey, FB API does not work!');
}
FB.getLoginStatus(function(response) {
clearTimeout(timeoutHandler); // This will clear the timeout in case of proper FB call
doSomeUsualWorkAfterFbReplies();
return false;
}, true);
}
If your application is in sandbox mode, Facebook acts as if your application is invisible to anyone who is not listed as an application developer. If you're not logged in, then it would stand to reason that your app is now invisible.
The callback will only fire if you're initializing with a visible application. Otherwise the following response is returned:
<span>Application Error: There was a problem getting data for the application you requested. The application may not be valid, or there may be a temporary glitch. Please try again later. </span>
For more info please see my comment on this bug ticket:
https://developers.facebook.com/bugs/240058389381072
Maybe you are using the asynchronous call. The same thing happened when I called FB.init with window.fbAsyncInit. All I did was delay the FB.getLoginStatus with a setTimeout function
window.setTimeout(checkLogStatus, 1000);
function checkLogStatus(){
alert("check");
// fetch the status on load
FB.getLoginStatus(handleSessionResponse);
}
It seemed to work after that
On the new version of the Developer app, you have to make sure to have put the correct URL you are using to access the application in the Website field under the
Select how your app integrates with Facebook
section.
Make sure the protocol is HTTPS and not HTTP.
I had a similar problem. The site worked every time when I was opening the browser, but fails when I tried to reload.
The cause was the missing "www" on the site name on Facebook configurations. Note that putting "www" (like www.yoursite.com) works on both situations (yoursite.com or www.yoursite.com).
As others have posted, you must be accessing your site at the same URL that facebook expects. For example if facebook has a callback "example.com" but you're browser has "www.example.com", that can cause this problem.
In addition, if third-party cookies are not allowed by your browser, you may also see this problem. Or you may see the callback erroneously reporting the user is not connected.
Just posting a situation I had were calling FB.getLoginStatus got absolutely no response.
My application is designed to run in a tab, and I only entered the Page Tab URLs on the app admin page, and not the App On Facebook (i.e. Canvas) URLs. The tab loads perfectly, but any calls to the FB JS SDK provoke no response.
In Facebook App Settings, go to Client OAuth Settings, look at Valid OAuth redirect URIs
Make sure you have listed all URIs which are the domains from which Facebook SDK is being invoked. For example:
I develop at localhost:5000 and deploy to Heroku. Notice the format: http://domain.name/