Does anyone know if it is possible to discover that a response from a WCF call in Silverlight resulted in a 302 (temporary redirect).
The 302 is generated because our service is behind ISA and the user session timesout. The Silverligt app remains loaded in the browser and the usre interacts to make a WCF call which fails. I can get a Not Found error but this is also reported for a number of different issues so not really a solution. I want to specifically target a 302 and refresh the page to get the user to reauthenticate.
I faced similar problem and luckily found a solution: to be able to retrieve StatusCode of a web request other than 200 or 404 you should use
var request = WebRequestCreator.ClientHttp.Create(uri)
instead of
var request = WebRequest.Create(uri) as HttpWebRequest;
I wrote a post on this issue recently, you can take a look here.
I was looking for an answer to the same question, but have decided not to use this approach to solve the problem I was dealing with, so I don't have a compelte solution for you, but if you are using Silverlight 3, then you may be able to solve it. I got as far as using the alternate Http stack as discussed at the bottom of this page:
http://developers.de/blogs/damir_dobric/archive/2009/08/22/soap-faults-and-new-network-stack-in-silverlight-3.aspx
This at least allowed me to gain access to SOAP faults, but I don't know if/how you can access HTTP 302 responses, since when I tried to do so, I found that Silverlight appeared to actually follow the redirect and re-issue my SOAP request there rather than report it back to my application.
What I did start investigating though is how this might be changed using behaviors. I didn't get very far with this investigation though so don't know if its feasible or not!
Related
I'm still very new to React so forgive me if the question is too naive. To my understand, React usually requires an API to do XHR requests. So someone with very basic tech background can easily figure out what the api looks like by looking at the network tab in web browser's debug console.
For example, people might find a page that calls to api https://www.example.com/product/1, then they can just do brute force scraping on product id 1 - 10000 to get data for all products.
https://www.example.com/api/v1/product/1
https://www.example.com/api/v1/product/2
https://www.example.com/api/v1/product/3
https://www.example.com/api/v1/product/4
https://www.example.com/api/v1/product/5
https://www.example.com/api/v1/product/6
...
Even with user auth, one can just use same cookie or token when they login to make the call and get the data.
So what is the best way to prevent scraping on React app? or maybe the api shouldn't be designed as such, hence I'm just asking the wrong question?
Here are some suggestions to address the issue you're facing:
This is a common problem. You need to solve it by using id's that are GUID's and not sequentially generated integers.
Restricting to the same-origin won't work because someone can make a request through Postman or Insomnia or Curl.
You can also introduce rate-limiting
In addition, you can invalidate your token after a certain number of requests or require it to be renewed after every 10 requests
I think no matter what you do to the JavaScript code, reading your API endpoint is the easiest thing in the world(Wireshark is an easy, bad example), once it is called upon from the browser. Expect it to be public, with that said, protecting it it is easier than you might anticipate.
Access-Control-Allow-Origin is your friend
Only allow requests to come from given urls. This may or may not allow GET requests but it will always allow direct access on GET routes. Keep that in mind.
PHP Example
$origin = $_SERVER['HTTP_ORIGIN'];
$allowed_domains = [
'http://mysite1.com',
'https://www.mysite2.com',
'http://www.mysite2.com',
];
if (in_array($origin, $allowed_domains)) {
header('Access-Control-Allow-Origin: ' . $origin);
}
Use some form of token that can be validated
This is another conventional approach, and you can find more about this here: https://www.owasp.org/index.php/REST_Security_Cheat_Sheet
Cheers!
EDIT: Looks like this post is much ado about nothing, as the OPTIONS preflighting was introduced late last fall; my problems have been more user error than anything. See comments for more details (I'll leave it all here for documentation's sake). --jlm
It's a known issue that the Youtube API does not support the OPTIONS request method, so any web app that tries to do a Cross-Origin preflight will fail, even if (as is the case with the Youtube API) the actual CORS request would succeed. As we've been facing this issue yet again this week, we've come up with three workarounds; however, each has it's own plusses and minuses.
POSSIBLE WORKAROUND #1: Forget the preflight, and just make the simple cross-origin request.
Benefits -- A) it works. B) this is all the specification requires when doing most GET or POST requests.
Drawbacks -- A) The specification states that any PATCH, PUT, or DELETE requests, along with POST requests that use a content-type other than form-data, url-encoded, or text/plain, need to be preflighted. So while it would work, it would be breaking the spec (which we'd like to avoid if possible). B) Preflighting is also necessary when setting custom headers; so, for example, when I use AngularJS's $http method in the 1.0 branch, it sets a custom header and thus triggers preflighting of even GET requests. In this case, of course, I could write my own $http service or move to the 1.1 branch (as the problem would really be on Angluar's end).
POSSIBLE WORKAROUND #2: Use JSON-P
Benefits -- A) it works, too (in some cases, anyway). B) It's fairly simple to set up.
Drawbacks -- A) An older technology, and it isn't clear if the Youtube API will continue to support JSONP. B) Requires a callback. C) Is limited to GET requests only.
POSSIBLE WORKAROUND #3: Set up a server-side proxy on the same domain, use it to communicate with the Youtube API.
Benefits -- A) Avoids the need to do CORS requests at all, since the client works on the same origin and the server-side proxy has no need to preflight anything.
Drawbacks -- A) Can get complicated to set up, especially if trying to work with credentials (oAuth2 through a proxy can be quite the beast).
So that this post has an actual question (or several, actually)
What take do you have (for better for worse) on any or all of the workarounds above?
Has anyone implemented other solutions?
Is there any information as to if/when the Youtube servers might support the OPTIONS method?
Any and all comments are welcome -- and I apologize in advance if this isn't the best forum for such a question (although I'm hoping that by putting it here on Stack Overflow, it'll prove useful to others facing the same issue)
Youtube upload API(uploads.gdata.youtube.com) doesn't support CORS.
You may vote the issues here and here . There are also several forum posts about it. CORS is not working !
It seems Google is still working to fix it , though started working on it about an year ago so most likely the API will be deprecated before to have the issue fixed(as we already have a V3).
The only workaround is to use a proxy(which is not cool). Basically upload the video on your server and then send it to youtube.
I've got a Silverlight application that makes a cross-domain request. The clientaccesspolicy.xml file exists on the server I am making a request to and is correctly configured.
I know that it is correctly configured because when I use the application to make a request from my machine I receive a response with no problem.
When a second individual on a corporate network about 300 miles away tries to use the same application, launched from the same URL, to make the same request, he instead gets a security exception.
Here's the odd part. I requested that he download Fiddler so that I could see the request and it's response, and thereby gain some insight into the problem, but when he runs the app with Fiddler open, the request succeeds.
This happens in both Chrome and IE. With Fiddler everything is fine. Without it, it doesn't work.
We've tried clearing his history, deleting the Silverlight app from the cache, everything I can think of.
The request is being made to a private network (which he is on), I make the request through a VPN connection to that network (in case for some reason that matters).
Any thoughts as to what's causing this bizarre problem?
Despite the fact the Fiddler "fixes" the issue it would still be worth while getting this second individual to save a .saz file from fiddler for the successfull set of sessions and then for you to compare them with a successfull set you have from your own machine.
An analysis of the differences may reveal a potential cause when fiddler is not in place.
Another approach would be to use a network protocol anaylser such as Wireshark. The elimination of the proxy that Fiddler represents may be enough to expose the problem, of course such tool is much more technical.
This post is simply to catalog the solution for future users. Thanks to everyone who helped.
The actual problem turned out to be (just as EricLaw -MSFT- suggested) that the client's machine was zoning the request URL as Intranet and the Silverlight application as Internet, and I am not permitted to make requests across zones.
EricLaw's direct responses may be viewed in the comments under the original question.
The URL below (provided by Eric) contains information regarding the denial of cross-zone request, as well as solutions.
msdn.microsoft.com/en-us/library/bb250483(VS.85).aspx
I'm getting a strange error in my newly deployed application in appengine. In the error log it tells me that PageRank, TwitterBot and a couple of others. I would guess this is due to these try to get data using ajax or another async service resulting in "same origin policy"-problem.
My question is does anyone know what these bots are trying to get? For example if pagerank (google page rank I would guess) can't get any info about my application would this effect my page rank. And anyone know what the twitterbot does? And if there is away to handle to provide a proper response?
Most likely, your RequestHandlers (I'm assuming you're using python with webapp from the tags on your earlier questions) aren't implementing a method for whichever request method the bots are using. I'd guess they're HEAD requests, and you have no head() methods defined.
Ok this is going to seem really daft but but essentially this is what i'm trying to do in a nutshell ...
http://msdn.microsoft.com/en-us/library/dd465161.aspx
The problem is that when I create the WCF Data Service and browse to it everything looks good at the root level and as soon as I leave the root I get http 500 errors.
I get no decent information on how to fix the error or what went wrong it says "Internal server error" ... not helpful.
So my question is sort of twofold ...
How do I setup a simple WCF Data service that relies on an entity model then bind some simple data to a listbox or something in a WPF client?
but also ...
How do I debug those http 500 errors?
Just for clarification:
I followed the steps here ...
http://msdn.microsoft.com/en-us/library/dd728275.aspx
... to create the model and service.
The root url "http://localhost/Northwind.svc" works fine.
Browsing to "http://localhost/Northwind.svc/Orders" causes a http 500.
This helps a LOT:
Link
Also download fiddler you can use it to monitor requests/responses (See this)
I would start by attaching the debugger to your service when you use your browser to access it.
You might want to try a different client because there usually is a response from a service besides the 500 errorcode, but a browser only shows a 500 error page.