I've configured the App RTC Server in my PC. When I am accessing using local host (localhost:3000). The Video call is working. But when I am using IP address getting the error. (http://192.168.0.103:3000)
Failed to get access to local media. Error name was
PermissionDeniedError. Continuing without sending a stream.
Error getting user media. Only secure origins are allowed.
getUsermedia error: Failed to get access to local media.
getUserMedianeeds HTTPS to work. You'll have to implement HTTPS for your webserver. localhost is the only domain allowed to use getUserMedia without HTTPS.
Related
I have a tt-rss server I host behind a Trafik instance. The host is something like ttrss.example.com and I access it on the web like https://ttrss.example.com. It works just fine anywhere on the internet.
When I try to make a request like
AF
.request(
"\(url)/api",
method: .post,
parameters: ["user": user, "password": password],
encoding: JSONEncoding.default
)
.responseDecodable(of: SessionResponseModel.self) { response in
debugPrint("Response: \(response)")
}
I get an error like
2022-09-29 21:24:36.652181-0400 ttc[89065:7539083] Task <808A492A-D131-448F-ADFD-4EE7158251D9>.<2> finished with error [-1022] Error Domain=NSURLErrorDomain Code=-1022 "The resource could not be loaded because the App Transport Security policy requires the use of a secure connection." UserInfo={NSLocalizedDescription=The resource could not be loaded because the App Transport Security policy requires the use of a secure connection., NSErrorFailingURLStringKey=http://ttrss.example.com:8889/api/, NSErrorFailingURLKey=http://ttrss.example.com:8889/api/, _NSURLErrorRelatedURLSessionTaskErrorKey=(
"LocalDataTask <808A492A-D131-448F-ADFD-4EE7158251D9>.<2>"
), _NSURLErrorFailingURLSessionTaskErrorKey=LocalDataTask <808A492A-D131-448F-ADFD-4EE7158251D9>.<2>, NSUnderlyingError=0x600002b39e60 {Error Domain=kCFErrorDomainCFNetwork Code=-1022 "(null)"}}
As you can see somewhere along the line Alamofire modified my url. Incidentally 8889 is the port my tt-rss server is running at behind Traefik.
My question is: why is Alamofire not just using the url I provide and like... Further resolving the url, but only partially?
I don't think this is an issue with neither tt-rss nor Traefik because both of those things are working just fine on every other part of the internet. There could be some config I am missing in Trafik that Alamofire needs, but beyond that I am not sure what I am doing wrong here.
Edit: I no longer thing this is Alamofire doing this. I believe it's Swift or iOS that's resolving the URL improperly (according to me).
If you read the error, this is an App Transport Security error, meaning the system wasn't able to securely connect based on the default ATS rules. In your case it's because you're not using https at all. You either need to connect using https, or if you can't, enable insecure connections for that domain using the methods indicated in Apple's documentation.
I'm trying to make a GET request from an iPhone app(built on Worklight), to a remote worklight adapter on a remote server.
I have generated the authorization request header using the following
http://remote-url:port/project/authorization/v1/testtoken
However, I keep getting the following cross domain error:
XMLHttpRequest cannot load https://remote-url/project/adapters/call/mq/getAccounts/22. Response to preflight request doesn't pass access control check: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://myapp-url:port' is therefore not allowed access.
But, when I try do the same GET request using an API tool like Postman, I receive the results no issues on my browser.
First - testtoken is only available from the MobileFirst Studio development environment... you need to take this into consideration.
Second, you're likely using Chrome and Crome disallows CORS by default. Change your browser settings and/or try in a different browser.
I am trying to connect to a Twitter API endpoint (https) from a Vagrant box (Laravel Homestead), however, I get a 401 authorization required when I try to connect.
On my local machine, everything works well. I am trying to figure out what is different in configuration, but no success. Does it has to do with the OAuth header?
You will need to update your oauth_callback to use your VM's ip instead of "localhost".
A good thing to do might be using this vagrant plugin vagrant-hostsupdater. Then you can set the VM hostname to something like "myproject.dev" and use that as the callback.
I have an RoR app and while deleting content from this app, I am encountering the following error. Although when I refresh the webpage after this error, the content is deleted in the request.
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request POST /abc/xyz/source/23.
Reason: Error reading from remote server.
This is an Apache Web server.
Can you please help me find what could be the reason behind this ?
The invalid response from an upstream server is generated when Apache web server does not receive a valid HTTP response from the upstream server.
The reason may be because of the following things;
The application did not respond in time and the request from Apache timed out.
May be network device blocking the request.
You need to add/increase the timeout limit in httpd.conf file of your application.
Whenever I try to call Magento's rest resources via PHP, I get an HTTP 500 Internal Server Error. My link is, in accordance to Magento's REST API, http://mymagento.com/api/rest/products.
Everything is set up properly and whenever I try to access it via the browser, the response is a page with the XML data I want. Same thing goes for the RESTClient plugin for Firefox.
I also get the internal server error whenever I try to do an authorised request as a customer.
Does anyone know why this is happening? I ran out of ideas an hour ago or so.
If you just got that problem (only) then,
500 errors in the HTTP cycle
Any client (e.g. your Web browser or our CheckUpDown robot) goes through the following cycle when it communicates with the Web server:
Obtain an IP address from the IP name of the site (the site URL
without the leading 'http://'). This lookup (conversion of IP name to
IP address) is provided by domain name servers (DNSs).
Open an IP socket connection to that IP address.
Write an HTTP data stream through that socket.
Receive an HTTP data stream back from the Web server in response.
This data stream contains status codes whose values are determined by
the HTTP protocol. Parse this data stream for status codes and other
useful information.
This error occurs in the final step above when the client receives an HTTP status code that it recognises as '500'. (Last updated: March 2012).
Fixing 500 errors - general
This error can only be resolved by fixes to the Web server software. It is not a client-side problem. It is up to the operators of the Web server site to locate and analyse the logs which should give further information about the error.