i have a page that is hosted on both HTTP and HTTPS, and it makes a HTTP call with jquery to a local http server on the client computer with the following code:
var url = "http://127.0.0.1:1234/Ping";
var ajaxSettings = {
url: url,
timeout: 1000
};
return $.ajax(ajaxSettings);
the client application has the following headers:
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: GET
Access-Control-Allow-Headers: Accept, Origin, Content-type
This works great when using http but when using https i get a error.
Is there any way to solve this? (generating a ssl certificate and registering it seems a bit overkill)
Related
I am trying to do PKI based authentication over proxy.
It works well without proxy, but asa I add proxy info it returns 401 error.
proxies = {
'http': "http://10.192.72.155:8080",
'https': "http://10.192.72.155:8080",
}
def open_url(url, key, cert):
headers = {"User-Agent": "<custom>", "Accept": "<custom>"}
response = requests.get(url, headers=headers, cert=(cert,key), timeout=300)
print response.headers, response
open_url("https://api.example.com/product/LatestUpdate", "/usr/bin/dev_certs/test_cert.key", "/usr/bin/dev_certs/test_cert.pem")
The above implementation works well, untill I add proxies to the requests.get()
response = requests.get(url, headers=headers, proxies=proxies, cert=(cert,key), timeout=300)
which returns following error:
HTTP/1.0 401 Unauthorized
WWW-Authenticate: Basic realm=""
Server: SomeServer
Connection: Keep-Alive
Content-Length: 35
The issue was my proxy setup, it was also decrypting HTTPS traffic, because of which it was not passing the original Certificate. It worked after I disable HTTPS decryption.
I am trying to verify an ID Token using the Firebase Admin SDK as per instructions. My current auth code looks like this (in Vue):
// Auth.vue, inside the firebaseui config callback
signInSuccessWithAuthResult: function(authResult, redirectUrl) {
authResult.user
.getIdToken(/* forceRefresh */ true)
.then(function(idToken) {
// Send token to your backend via HTTPS
// ...
console.log(idToken);
})
.catch(function(error) {
// Handle error
console.log(error);
});
The login works fine and I can get authResult perfectly. However, it seems the function getIdToken is the problem, as I get the following error on my console:
Cross-Origin Request Blocked:
The Same Origin Policy disallows reading the remote resource at
https://securetoken.googleapis.com/v1/token?key=AIzaSyApp5yu051vMJlNLoQ1ngVSd-f2k7Pdavc.
(Reason: CORS request did not succeed).
In my request list, the one hanging is an OPTIONS method, with the following headers:
OPTIONS /v1/token?key=AIzaSyApp5yu051vMJlNLoQ1ngVSd-f2k7Pdavc HTTP/1.1
Host: securetoken.googleapis.com
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:62.0) Gecko/20100101 Firefox/62.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.8,pt-BR;q=0.5,de;q=0.3
Accept-Encoding: gzip, deflate, br
Access-Control-Request-Method: POST
Access-Control-Request-Headers: x-client-version
Origin: http://localhost:8080
Connection: keep-alive
Pragma: no-cache
Cache-Control: no-cache
I am not even sure where the problem lies. Is it coming from the Vue side? I am running it in a dev server (by simple yarn serve, vue cli 3). Would the solution be when I run Vue on a production server where I can actually configure cors?
Any light on the matter is extremely welcome...
Thanks!!
Figured it out.
I was calling it in the wrong place. What helped was this thread, which pointed me out to Preflighted Requests which is what the OPTIONS request is:
"preflighted" requests first send an HTTP request by the OPTIONS method to the resource on the other domain, in order to determine whether the actual request is safe to send. Cross-site requests are preflighted like this since they may have implications to user data.
So I realized I should not be sending this request within my Post request where I got the authorization in the first place. Moving it to another method made it work.
I used this api call to get DNS records and nameservers using domain name
https://api.godaddy.com/v1/domains/testsd34.com/records/NS
GetRecords here is the api call
For default godaddy nameservers its giving everything perfectly but whenever i am using custom nameservers for domain that time this api call not giving nameservers in response its giving empty array,
anyone knows how to get custom nameservers using this api call?
Finally, I found a way to get and edit nameservers for domain.
(For custom nameservers, records are not set by GoDaddy, therefore you have to
query nameserver provider.)
Following is the API call for getting nameservers:
HTTP request:
GET https://api.godaddy.com/api/v1/domains/mydomain.com
HTTP headers:
Authorization -> sso-key my-key:my-secret
Content-Type -> application/json
Response will contain JSON object which has key "nameservers"
with pair of nameservers that you have. Example:
"nameServers": [
"ns1.mynameservers.com",
"ns2.mynameservers.com"
]
To edit the nameservers via API call, you can use following API call:
HTTP request:
PATCH https://api.godaddy.com/api/v1/domains/mydomain.com
HTTP headers:
Authorization -> sso-key my-key:my-secret
Content-Type -> application/json
HTTP body:
{
"nameServers": [
"ns3.mynameservers.com",
"ns4.mynameservers.com"
]
}
I am trying to upload an image to a finagle (netty) server. For the OPTIONS request I return the following:
curl -X OPTIONS http://localhost:8686/images -i
HTTP/1.1 200 OK
Access-Control-Allow-Origin: *
Access-Control-Allow-Methods: POST
Browser (FireBug): http://s15.postimg.org/vtdzyfshn/Screen_Shot_2014_09_02_at_9_49_05_PM.png
The following POST request fails with
Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote
resource at http://localhost:8686/images. This can be fixed by moving the resource
to the same domain or enabling CORS.
FireBug 1 (Console): http://s30.postimg.org/9utq4ridt/Screen_Shot_2014_09_02_at_9_53_41_PM.png
FireBug 2 (Net Tab): http://s16.postimg.org/jyblxfcv9/Screen_Shot_2014_09_02_at_9_54_37_PM.png
FireBug 3 (Net Tab - POST): http://s14.postimg.org/e8czua2wh/Screen_Shot_2014_09_02_at_9_54_47_PM.png
Any idea what I am missing?
(I am using this upload script: http://www.extremecss.com/creating-asynchronous-file-upload-system-using-html5-file-api/
You have to return the CORS headers (Access-Control-Allow-Origin: *) within the response header to your POST as well, instead of just within the OPTIONS response.
Here's what happens on the local server when application invokes HTTP request on local IIS.
request.Credentials = CredentialCache.DefaultNetworkCredentials;
request.PreAuthenticate = true;
request.KeepAlive = true;
When I execute the request, I can see the following series of HTTP calls in Fiddler:
Request without authorization header, results in 401 with WWW-Authenticate NTLM+Negotiate
Request with Authorization: Negotiate (Base64 string 1), results in 401 with WWW-Authenticate: Negotiate (Base64 string 2)
Request with Authorization: Negotiate (Base64 string 3), results in 401 with WWW-Authenticate: Negotiate (Base64 string 4)
Request with Authorization: Negotiate (Base64 string 3), results in 401 with WWW-Authenticate NTLM+Negotiate
Apparently the client and the server (both running on the same machine) are trying to handshake, but in the end authorization fails.
What is strange is that if I disable Windows authentication of the site and enable Basic authentication and send user/pwd explicitly, it all works. It also works if I use NTLM authentication and try to access the site from the browser specifying my credentials.
Well, after several hours of struggling I figured what the problem was. In order to be able to inspect network traffic in Fiddler I defined a Fiddler rule:
if (oSession.HostnameIs("MYAPP")) { oSession.host = "127.0.0.1"; }
Then I used "MYAPP" instead of "localhost" in the Web app reference, and Fiddler happily displayed all session information.
But server security was far less happy, so this alias basically broke challenge-response authentication on the local server. Once I replaced the alias with "localhost", it all worked.