I finished setting up the webservice routes according to Apple documentation and I am able to sign and provide passes. Unfortunately I am experiencing the following problem. When I define the webServiceUrl as "https://localhost:5000/wallet/" the signing of the pass works as expected. I am then using the pass in the iOS Simulator where I have enabled the "Allow Http Services" in the developer settings but I am still getting the "An SSL error has occurred and a secure connection to the server cannot be made" error. Trying then to use http instead of https directly in the definition of the webServiceUrl in the pass.json file produces a signing error. Do you know which steps have to be made to be able to test pass updates locally?
The warning is telling you everything you need to know.
Change your webServiceUrl to http://localhost:5000/wallet/. The developer option means that you don't have to use https and the pass should still install on any device with "Allow Http Services" set.
Related
I am using Angular Capacitor v3 with axios. Receiving a Network Error when making any request to any external server. This is only occurring while emulating with XCode. The request never reaches the server, just returns immediately with status 0.
I cannot repeat this problem locally on Windows, or published website, or Android Studio emulators, or published to android device.
Not sure if I am missing a permission or configuration, but I have tried adding "Local Network Usage", "Location Always and When In Use" permissions and played around with NSAppTransportSecurity settings to the Info.plist.
I do not believe its an issue with the server since it seems like it never even reaches it. But I have a verified HTTPS certificate, hosted by Azure, with valid CORS rules.
I have also tried HttpClient with Angular, same result.
The error occurs immediately and does not give specific information but here is the message:
{"headers":{"normalizedNames":{},"lazyUpdate":null,"headers":{}},"status":0,"statusText":"Unknown
Error","url":"https://jsonplaceholder.typicode.com/users/1","ok":false,"name":"HttpErrorResponse","message":"Http
failure response for https://jsonplaceholder.typicode.com/users/1: 0
Unknown Error","error":{"isTrusted":true}}
After extensive research and rebuilding from scratch, I found this was a CORS related issue but specific to setup with Azure, which was my hosted server. The confusing part was that even external example calls, such as to "http://jsonplaceholder.typicode.com/users/1" still gave the same error, which wouldn't have CORS issues, as far as I understand. If anyone knows why that happens, please let me know.
This was related to the fact that in ios, the http/https schemes cannot be used, instead it uses capacitor. This scheme is not allowed in Azure App Service CORS settings, unless you allow all, but I could not because I needed to enable Access-Control-Allow-Credentials. So I had to build the CORS configuration with the capacitor scheme allowed in my C# app service code. Removing all settings from CORS in Azure App Service then allowed the settings in my C# code to be applied.
I am just facing same issue
It was working on different domain, no hostname is different and it stopped working.
So it doesn't even make a request to a server.
Also same configuration works on android. just not IOS
Unable to open pkpass when I try I get the error "The pass “pass.pkpass” could not be opened".
When I try to open it in a simulator it works so I don't have a way to debug it. Any ideas?
Your pass is failing to load because your web service URL is not being served over HTTPS.
error 21:40:19.322330 +0800 Pass Viewer scheme of webServiceURL 'http://xxx.yyy-qa.com:8091/api/' needs to be an https rather than http.
To fix, either serve your web service over HTTPS, or hook your phone up to Xcode, enable developer mode, then check the option to allow HTTP for passes.
I have preare a API call using HTTPClient(titanium ios mobile application).
it is a Login page so ihave use https protocal,(https"//example.com)
but it returns a following error message,
"A connection failiure Occured. SSL problem(Possible causes: SSL may include a bad/expired/self-signed certificate,clock set to wrong date".
But the same https url has work fine in Rest Client(Google App), so from web site has SSL authority.
i have work to solve this issue over a whole day,
How can i solve this issue?
Note: if i used validatesSecureCertificate : false its works. but i want a secure connection. so i want to works even i set this as validatesSecureCertificate : true.
All websites mention that Passbook passes can be sent by e-mail. But when the pass (generated by our server) is attached to an e-mail, the iOS e-mail client won't open it and write "(null)" instead. The same pass works fine on Android and also has no problems communicating with our web service. Any ideas? Google searches didn't offer any solutions.
Screenshot:
Solved: There were multiple problems:
The authentication token has to be at least 16 characters long
I used the "Apple Inc. Root Certificate" (wrong one) instead of the "AppleWWDRCA" (correct one)
For production the web service needs to use https
You get that when the pass in invalid, most likely due to it being incorrectly signed and/or the pass certificate has expired.
Drag your pass into iPhone Simulator and check the Console app to look for error in the logs.
I have a custom mdm solution running for IOS.
during enrollment, I am using HTTP basic authentication to pass the user name and password to be verified against our db/AD.
if the user is denied access, I send a 401.
however, on the IOS side, it pops up an error that says "safari could not install a profile due to an unknown error". Seems like a pretty bad error where I want it to say access denied.
Also there's an issue that safari decides to cache the credential used, so I don't get a chance to re-enter the user/pass again unless I clear all the cookie/cache data.
Anyone have met this issue before?
Looks to be issue with my code.
I've sent a 401, but actually the specification calls for a WWW-Authenticate header to be sent as well. With that added it, it's working normally now.
Have you considered using a more widely tested MDM solution such as AirWatch? A solution such as this has integration with AD and would be an excellent option for you to evaluate.