I'm trying to make an API request to the ServiceM8 REST endpoints from my browser using AJAX. I'm basically having the same problem as this unresolved issue that was posted on the ServiceM8 discussion board:
https://developer.servicem8.com/discuss/5a0e0513ff22d5001e9587f6
Is there currently no CORS support integrated into ServiceM8 to allow this?
I contacted the ServiceM8 Helpdesk and they confirmed the was an issue that has now been resolved.
Trying it on test-cors.org appears to work:
https://www.test-cors.org/#?client_method=GET&client_credentials=false&server_url=https%3A%2F%2Fapi.servicem8.com%2Fapi_1.0%2Fjob.json&server_enable=true&server_status=200&server_credentials=false&server_tabs=remote
Related
I am using create-react-app to build an application that utilizes the Agora API. While trying to do so I receive a "No 'Access-Control-Allow-Origin' header is present on the requested resource" error in my browser's console. I understand this is caused by CORS and that the API doesn't have an Access-Control-Allow-Origin header.
I have tried to deal with it using: https://www.telerik.com/blogs/dealing-with-cors-in-create-react-app by adding
"proxy": "https://sua-ap-web-1.agora.io"
to packaage.json, however this does not work. I am considering setting up a Node.JS proxy server as described here, but do not know if it would work to resolve the problem and if I should spend time going down that rabbit hole or if there is a better alternative.
I did notice that #plutoless on agora's github mentions that API calls should be made from the server end and not client side like React or AngularJS.
So the question is, is there a way to make API calls using ReactJS without having to setup a proxy server?
Finally got this to work, thanks #AkshatGupta for helping me identify the problem. I switched the sdk I was using from
"agora-rtc-sdk": "^3.4.0"
to using
"agora-rtc-sdk-ng": "^4.0.1"
and it started working perfectly. I do not yet understand the underlying problem for this issue however this worked for me. Do note that I did not have to setup a proxy server or setup a proxy field in package.json as I mentioned in the question.
We are using JSONP approach to load instagram embed posts, however recently we got an issues with response content-type mime-type mismatch.
Any solutions to fix JSONP approach without switching to embed.js or to json?
Cross-Origin Read Blocking (CORB) blocked cross-origin response https://api.instagram.com/oembed/?url=https://www.instagram.com/p/BJPIEc8BHEI/&hidecaption=false&callback=_jsonp_instagramImage_0 with MIME type application/json. See https://www.chromestatus.com/feature/5629709824032768 for more details.
and IE:
The resource from ... was blocked due to MIME type mismatch
Loading just by creating <script> and callback
Facebook say:
This issue is related to the legacy Instagram API (api.instagram.com)
which isn't supported via this channel; this bug reporting tool only
supports issues related to the Instagram Graph API. Additionally, as
the legacy Instagram API has been deprecated as of July 2018, the team
is no longer accepted bug reports for this API. Thanks for your
understanding.
https://developers.facebook.com/bugs/235545030662906/
See also https://github.com/sugarshin/react-instagram-embed/issues/89.
I ran into a similar issue; it looks like Facebook changed their CORS policies a few days ago and didn't tell anybody. You'll have to work around CORS. I set up a php script to handle my GET request from my webapp, which in turn calls a python script to make the GET request and pass back the data. Happy to share the code if you'd like.
I have set up OAuth as per the docs and this link https://strongloop.com/strongblog/node-js-loopback-api-gateway-sample-applications/.
There are a few issues in understanding the usage of the code base and flow based on the options of loopback-component-oauth2. Is there a tutorial that covers each section or a working implementation for Implict, AuthorizationCode, Refresh token, JWT.
I have been able to secure API (eg: /api/Notes) as per docs and it does seem to be blocking requests but is not allowing me to authenticate. More, when I make a request to /oauth/token this API is also throwing Unauthorized 401 errors - both from REST Client like postman and https://loopbacklocalhost/explorer.
I am using loopback 3.0. I am having tough time with the component not documented completely nor having a doc aligned example code. May be I am missing something here.
I have seen this hub repo as well and seems they use passport directly and is documented very less making it difficult to integrate things easily.
https://github.com/strongloop/microgateway
Note: I have gone through the following question, the archive repo tests.
How to setup OAuth 2.0 server using loopback
Any help is welcome.
I am seeing this error from my live server using the Instagram API.
{
"Error":true,
"message":"Matching code was not found or was already used."
}
I have read a few suggestion on here to clear cache but that isn't fixing the issue. I am also unable to submit a support ticket directly on the Instagram site as I am receiving an error message while attempting to submit a ticket.
There are a bunch of developers complaining about the same issue at https://news.ycombinator.com/item?id=13178789. I don't think unchecking "Disable implicit OAuth" fixes the issue as I have already tried that and it didn't work.
The best thing you can do is to submit a report to instagram using your client id to put some pressure on their side to fix this issue.
I have the same issue, I guess it's from Instagram I reported an issue from my client panel in developer > manage clients > Report issue.
You can do they resolve this issue as soon as possible.
There is definitely a problem with the Instagram OAuth flow. The returned authorization code doesn't seem to work for some reason, it's very likely a network related problem that they need to fix on their end.
My theory is that the authorization code generated is not distributed to all Instagram API servers, and if you happen to hit a bad node then you're out of luck.
However, I recently found a solution that doesn't rely on the authorization code. If you use the client-side authentication then you'll be able to retrieve the access token without ever using the authorization code. It's less secure but works great as a temporary fix.
You simply change response_type=code to response_type=token. The token response type will redirect the user back to your website using this URL structure:
http://your-redirect-uri#access_token=ACCESS-TOKEN
I recommend fetching the access token from the URL client-side using JavaScript, and then passing it to an endpoint on your website. E.g. /callback?accesstoken={accessToken}. This is required because the content in the hash is not passed to the server.
Example:
<script>
if (window.location.hash && window.location.hash.indexOf('#access_token=') !== -1) {
var accessToken = window.location.hash.replace('#access_token=', '');
window.location.href = '/callback?accesstoken=' + accessToken;
}
</script>
The code snippet above is copied and slightly modified from the solution at https://news.ycombinator.com/item?id=13178789
You can read more about Instagram client side authentication on https://www.instagram.com/developer/authentication/ under Client-Side (Implicit) Authentication
I just had the same issue. Not sure why, but for me the code returned from oauth/authorize/? had 2 special characters at the end - "#_". After removing these my code worked.
This is due to security restrictions in place on your Instagram app. You can choose to allow it by unchecking "Disable implicit OAuth" for your Instagram app, under the Security tab.
I've just begun playing around with the Nest API and am having trouble understanding why the OAuth2 server will not redirect a response to my redirecturi.
Example of my authentication attempt url:
https://home.nest.com/login/oauth2?client_id={ClientId}&redirect_uri=http://localhost&state=STATE
I'm able to authenticate and get a PIN back but ideally this is a response sent back to me and handled in my app dynamically.
Nevermind - I realized how can it possibly redirect to my localhost. Oops!
Thanks for the comment David - I found the redirectURI on my clients page now...must have overlooked that before.