I have an azure web site that I don't update anymore.
So I edited the web.config and added a rule to redirect to a new URL.
I made a type when typing the new URL and set the redirect mode to permanent.
No matter what I do, now I can not correct it because it seems it's permanently stuck this way.
The old URL now tries to redirect to some random incorrect typo location.
Is there a way to reverse this?
This sounds like it may be a local issue. Your browser may have cached the 302 response. Have you tried using a different browser, or clearing your browser's cache?
Otherwise, have you restarted the web site through the Azure portal?
Related
I want to create and test an app initially from localhost (were I run Ruby on Rails or Glassfish). I have read many postings about how to do this and NONE work. I have tried all the solutions discussed on stackoverflow and other sites.
Does anyone have a current method that does work (2015)?
Following did not work
1) in Canvas URL http://localhost:3000/users/index/ with and without localhost as domains
2) Tried editing the Advanced tab to add redirect URL to same URL.
What happens is I get a blank screen (I have even tried really simple hello world type apps that run locally so it should work with facebook).
Thank you,
Lynne
you have to configure secure canvas URL for canvas apps . it is mandatory and it has to be a https URL.
edit: This is actually a lot easier than I thought. I found this python script that creates a local https server. The only issue was that facebook is sending a POST request on the canvas page, and this server doesn't support POST requests, so I modified it a bit and now it handles the facebook canvas page correctly.
You don't need a domain, and in the script it tells you how to generate the self signed certificate. In the facebook app settings you can set https://localhost:4443/ as canvas url.
old post:
It is possible but it's a bit of a hassle. You can set a dns to 127.0.0.1 and use that. So if you own example.com, you can create an A DNS record for localhost.example.com and set it to 127.0.0.1.
The difficult part is that you have to find some way to create a certificate for this domain. If you want an official cert, the easiest option out there is Let's Encrypt. Verification of your domain through an https server is going to be difficult, since the Let's Encrypt servers will try to contact 127.0.0.1. So you're probably better of using DNS challenge validation. Another option would be a self signed certificate, which is a whole different story.
The last step is to find a server that can host https and use the certificates you generated.
How are browsers implementing requests for Application Cache manifest files and is it different from how other files are requested?
I ask because I'm seeing behavior I wouldn't expect when using Windows/NTLM authentication in IIS 7. The situation is that I have a site with a manifest file defined. With anonymous authentication, everything works as expected -- the site loads and is available offline.
When I disable anonymous and enable Windows authentication, the site will load fine after authenticating, but I will see an error in the console (in Chrome or on an iPad 2) that says the manifest file could not be fetched.
On the iPad, the error is that the Application Cache file could not be fetched. In Chrome, the specific error is "Application Cache Error event: Manifest fetch failed (401)." I can see the 401 response code in the web server logs in both instances.
Why this behavior seems unexpected is requests for all other resources (CSS, JavaScript, images) all work as expected. Also, I can browse to my .appcache file and it loads.
Can anyone explain what's going on?
Has anyone else run into this and found a solution?
Not sure if this is still relevant, but I'm also having this problem.
As my site makes AJAX requests, once the page has loaded I am asked for credentials for the request to take place. Once this has happened, running applicationCache.update() causes the application cache to update correctly.
Therefore, as a work around, perhaps try making an AJAX request to something so that the user is prompted for credentials, then call applicationCache.update().
i have also run into this problem. Exactly as you described, but i am using basic auth on Apache. I am going to try making the the mainfest file public.
I know its an old question but i had the exact same problem which led me here.
my setup is:
server - IIS8
authentication - windows
anonymous authentication - enabled (did this so i could get my dynamic manifest to be fetched regardless of authentication, i had to then decorate all other controllers with [Authorize])
With the above setup the application would cache properly however when loading from the cache, if there was an update to the manifest certain sections were not fetching (such as authorized content) because the user was not "logged in" and hence making the whole update even fail.
My solution was to add in an ajax call to an authorized resource, this way when the user was online they would be prompted to log in meaning that the next time the cache was updated they were authorized again.
I'm retrofitting my application with GWT History support, and I've stumbled on a case where I'm not quite sure what to do. The answer to this question doesn't necessarily have to be GWT-related.
GWT's History support functions by passing around hash tags (i.e. index.html#token). Security restrictions require users be logged in prior to actually being able to access index.html, so they get sent over to a login page, retaining the token (login.html#token). So far, so good. Now the user becomes authenticated and Spring sends them over to index.html (the default target) and eliminates the #token part of the URL.
How can I force Spring Security to maintain the token and send my newly authenticated user to the page they requested (index.html#token)? Since I've already got Spring Security authentication working, I'd prefer to not restructure the way my app handles logins.
After a great deal of digging, I found my answer on Spring's Jira. As Colin Alworth stated, that token isn't actually part of the request, so Spring Security never sees it server-side, and thus can't use it to determine the final URL. So the approach I used was to append the hash (client-side) to j_spring_security_check, making it j_spring_security_check#token. Now the token gets passed along just fine, allowing me to have a well-secured app with working tokens.
Thanks for your help Colin, your answer got me thinking in the right direction.
The server doesn't get to see this token as part of the GET/POST request as you've noted, it is only seen by the browser. Best fix that I've seen for this in the past is for the login page to take note of the current window.location.hash, and pass that along, either along with the login form (assuming a redirect will take place that keeps the hash around), or to the server as a login param so it can redirect properly.
Here's what happens, it might help you solve the problem:
sending unauthenticated users from index.html to login.html is most
likely implemented as an HTTP 3xx redirect, and that's why the
browser keeps the hash fragment (#token).
Once they login, spring sends them from login.html to index.html not
via 3xx redirect so the browser doesn't keep the token.
One solution would be to inject the token into index.html, and pick it up with GWT. Another one is to make login.html -> index.html a 3xx redirect (if spring allows that).
So I did the misstake of using a temporary url a while ago when launching my web site and called it http://web.mysite.com
Now when google indexes it, even that the web. is not the primary url anymore it still uses that over the http://www.mysite.com
Is there any way I can change this? Unfortunately I cant remove the web.mysite.dom binding from IIS since all Google links refer to that and I cannot use wildcard binding on the actual server.
I have google analytics enabled with the correct url (www.mysite.com).
Is there a way to enter some kind of meta data that enforces the robots to see the address as www.mysite.com?
Thanks
Did resolve by creating the web.mysite.com and put a permanent redirect www.mysite.com (301). Also used google webmaster tools to ensure this was correctly done.
I want to delete record of those peoples who have remove app from their application's list, to do this I have entered that URL where I make a code to delete record of active user from my database in de-authorize callback. But still I'm unable to de-authorize users from by db.
Edit: See Facebook Deauthorize Callback over HTTPS for what my original problem really was. Summary: Improper web server configuration on my part.
Original answer was:
One potential problem has to do with https based deauthorize callbacks. At least some SSL certificates are not compatible with the Facebook back end servers that send the ping to the deauthorize callback. I was only able to process the data once I implemented a callback on an http based handler.
Some things to check...
That the URL of your server is visible from facebook's servers (ie not 192.168 or 10.0 unless you've got proper firewall and dns config).
Try using an anonymous surfing service and browsing to the URL you gave facebook - do you see a PHP Error?
Increase the loglevel for PHP and Apache/IIS to maximum and see if you get any more information
We can't do much more unless you give us your code...