I am trying to implement SquareUp Payment Gateway on a website and using Square Connect V2. When I try to show SqPaymentForm form in JavaScript but getting the following error -
paymentform:1 Uncaught Error: SqPaymentForm can only be embedded on sites that use HTTPS.
I can see a function named setSSLVerification in sample code but it not working and also I can't find it in API. I wonder if there is any way to turn SSL verification.
Can we turn off SSL verification? Like for development server?
Update:
After trying couple of unsuccessful things, I finally purchased SSL for dev server. As that's the easiest and quick solution. Thanks everyone for your answers.
You can use localhost for testing payment forms, but you are not able to use other development environments (like external testing servers). I'd recommend either testing from your local machine, or getting a free certificate with a service like Let's Encrypt
just use following code.
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
in your c# code for bypass the security of HTTPS.
Related
I'm curious if anyone else has encountered this issue.
I am building an application that will authenticate users using Google 0Auth 2.0 + OpenID.
I've built a simple site just with HTML and CSS to hold the UI and I'm using live server in Vscode to view it.
In The Google developer console for oauth, you must set Authorised JavaScript origins for client-side applications. I assumed I would just set this to http://localhost:5500 for the port that live server uses but I always get the following error:
Authorization Error
Error 400: invalid_request
Permission denied to generate login hint for target domain.
I have got around the issue by just getting a domain and hosting for a test site and setting this as the "Authorised JavaScript origin". However is seems really clunky and I have to FTP all my files to my hosting provider every time I want to change my code.
I could also host everything on a Node.js server from my local machine but this would just cause the same issue as before.
My question isn't so much how to stop getting this error but what is the proper way of developing with OAuth 2.0 and is there any way to speed up the process/create a local environment that doesn't get the same errors.
Thanks for your help.
There is an answer to this Google question here that may help you.
The way I have always set up an OAuth environment is to try to avoid localhost and use more real world URLs on a Developer PC. I also like to split them like this which helps me to visualize the architecture:
Base URL
Represents
http://www.example.com -
Your web UIs
http://api.ecample.com
Your APIs
http://login.example.com
The Authorization Server
This approach can also give you more confidence that your code will work well in beowsers, in areas such as these:
CORS
Cookies
Content Security Policy
By default you just need to edit your hosts file and add an entry like this. It can work very well for demos to business people also.
127.0.0.1 localhost www.example.com api.example.com login.example.com
:1 localhost
ADVANCED SCENARIOS
At Curity we provide some quite advanced developer setups and this approach scales well, as in the below articles. The second of these also provides a script you can use to run locally over SSL, in case this is ever useful:
Single Page Apps End to End Developer Setup
Kubermetes End to End Developer Setup
I am working on a video/audio chat application in React and Django using Mesibo Javascript SDK.
It is working locally on the same network but when trying to connect through different networks, Firefox browser gives me this error
WebRTC: ICE failed, add a TURN server and see about:webrtc for more
details.
In Chrome, this error doesn't show up but still the video/audio chat is not working and gives me
Mesibo_OnCallStatus: 50.
I noticed that Mesibo uses stun:stun.l.google.com:19302 as the STUN server and tried changing it to stun:stun.l.google.com:19305 but of no use. I even created a numb.viagenie.ca account to add a TURN server which worked for a few minutes and then gave this error
webrtc: ice failed, your turn server appears to be broken.
When checked on https://webrtc.github.io/samples/src/content/peerconnection/trickle-ice/, chrome is giving error code:701 for all the above turn/stun servers whereas firefox doesn't.
As suggested by Mesibo Documentation, my website is fully secure with https and the Rest APIs are called from Django backend. I'm invoking https://api.mesibo.com/mesibo.js as a script tag in the index.html file in react. I'm also able to successfully get
Mesibo_OnConnectionStatus=1
and the incoming call notification is also working. Upon answering the call, the call status changes from 3 to 5 and gives this webrtc error after sometime without any video/audio rendered.
Please suggest any hint/solution.
To Enable webrtc for remote calling you need your own trun server.
Google don't provide free trun server.
Free Turn Servers are will not work well in production. Well Fell Free to try Your Luck on Them. Not All Are borken
You Need to create Your Own on Cloud like DigitalOcean,AWS.
Or For Tetsing purpose I have a Trick
Soloution.
If Your Doing the testing
Probably you can try to use some Google TURN servers that they use here
https://test.webrtc.org/, I just checked for browser console and found this:
enter image description here
Not Sure About LifeTime. But you will get that.
For Production I will suggest to used DigitalOcean 5$ plan which is very chip.
And you install your own TURN server using coturn on it
If you want You can also use
Node-turn
which is great for node backend.
There is also heroku option of setup
I don't know is there any django or python option.
(tip: try your to build turn server on hosting server. Make sure the port on which server is running is open)
I have made a game called kotakio (with nodejs), and have it hosted on kotakio.herokuapp.com, I now have a custom domain name, under kotak.io, but when I try and go on it, it says that my connection isn't secure, I think this is because it uses the certificate for *.herokuapp.com, as it says that the server may be trying to trick me. Is there a way for me to prevent this without having to buy the SSL Endpoint addon, as it's 20$/month, and this is only a hobby project.
If you use hobby or professional dynos you could try the beta for default ssl encryption with no additional charges. Otherwise the only way to use custom domains with ssl without that warning is adding the addon...
I am trying to implement my site with SSL. I used the IIS to create a self-signed certificate. But when calling the site using https I keep getting ERR_INSECURE_RESPONSE and never seem to reach the server.
I use Chrome extension 'Advanced Rest client' to call the server.
I have no clue to what to do, appreciate the help...
Recreate the self signed certificate using the following tutorial -
https://technet.microsoft.com/en-us/library/cc753127(v=ws.10).aspx
I've never seen this error specifically but suspect there is an issue with the certificate.
I'm using subscribe endpoint of Instagram and it gives me the following error message if my callback_url is HTTPS; it works fine if callback_url is HTTP; the error message:
{
"meta": {
"error_type": "APISubscriptionError",
"code": 400,
"error_message": "Invalid SSL certificate"
}
}
PS: I saw this thread saying "I think this because I checked the SSL certificate for api.instagram.com and it looks OK"; But I dont know where they exactly checked SSL certificate? I dont see this option in Instagram developer console...
Does this mean the callback_url cannot be HTTPS?
Any idea how I can solve it?
Your Callback URL is probably self-signed certificate. Instagram does not support self-signed certificates.
So you have to use HTTP or Get an SSL certificate for your website.
Also check this thread: https://groups.google.com/forum/?fromgroups=#!topic/instagram-api-developers/MaS4fjo8GXQ
Hey folks,
We've made a couple of changes recently that affected the realtime
API, and we wanted to update you all:
1) We centralized some of our error tracking, which made our previous
"blacklisting" rate limits too aggressive; we've identified this and
have raised these errors, resulting in fewer false positives
2) We
switched the library used for the POST requests, which had the
side-effect of starting to enforce proper SSL certificates. If you've
noticed a drop-off in realtime hooks, please double-check that your
certificate is valid on your host. Going forward, this check will be
made when creating subscriptions, too, so incorrect subscriptions
won't be created.
3) Finally, we've updated the documentation to
reflect that http://ec2-... URLs are often problematic (as we're on
Amazon and they will often resolve locally) and we instead recommend
using the public IP or an Elastic IP for that host.
Thanks, Mike