When we're building our Angular SPA for localhost it works perfectly.
On our dev environment, this error creeps into the DevTool console and breaks everything:
ERROR Error: Uncaught (in promise): TypeError: Cannot read property 'digest' of undefined
TypeError: Cannot read property 'digest' of undefined
at N (auth0-spa-js.production.js:1)
at ie.<anonymous> (auth0-spa-js.production.js:1)
at Generator.next (<anonymous>)
at auth0-spa-js.production.js:1
at new ZoneAwarePromise (zone-evergreen.js:876)
at t (auth0-spa-js.production.js:1)
at ie.loginWithRedirect (auth0-spa-js.production.js:1)
at AuthGuard.<anonymous> (auth.guard.ts:22)
at Generator.next (<anonymous>)
at fulfilled (environment.ts:11)
at resolvePromise (zone-evergreen.js:797)
at new ZoneAwarePromise (zone-evergreen.js:879)
at t (auth0-spa-js.production.js:1)
at ie.loginWithRedirect (auth0-spa-js.production.js:1)
at AuthGuard.<anonymous> (auth.guard.ts:22)
at Generator.next (<anonymous>)
at fulfilled (environment.ts:11)
at ZoneDelegate.invoke (zone-evergreen.js:359)
at Object.onInvoke (core.js:34195)
at ZoneDelegate.invoke (zone-evergreen.js:358)
I guess it must be something about the build process, some different flags, but I can't figure out exactly which.
It's probably because your dev server is setup as an insecure origin.
The digest likely refers to window.crypto.subtle.digest of the Web Crypto API. if you are using a Chromium-based browser, according to the the Chromium Projects page here, the subtle property can only be used in a secure origin:
Access to the WebCrypto API is restricted to secure origins (which is to say https:// pages).
Note: In the spec, crypto.subtle is supposed to be undefined in insecure contexts
Because digest is a method of subtle, and subtle is undefined, you are getting this error.
We got the same error when using the auth0-spa-js library. It worked on localhost, not on our http staging site, but OK on our production https site.
If you aren't in a secure origin, try making your dev environment secure and then testing again (a self-signed certificate should do). As a reminder, secure origins are:
Which origins are "secure"?
Secure origins are those that match at least one of the following (scheme, host, port) patterns:
(https, *, *)
(wss, *, *)
(*, localhost, *)
(*, 127/8, *)
(*, ::1/128, *)
(file, *, —)
(chrome-extension, *, —)
That is, secure origins are those that load resources either from the local machine (necessarily trusted) or over the network from a cryptographically-authenticated server.
I'm not sure if the Auth0 team have an SPA library that works in a non-secure origin (or plans to enable that capability in their latest SPA library), but their native JS libraries definitely do.
Angular framework:
Getting an HTTPS by configuring a SSL certificate to your application's nginx (nginx.conf or app.conf) solves this problem.
Assign a ssl certificate and ssl key for your domain. Make sure to change your port to 443.
This seems more related to Angular than Auth0 but out of curiosity have you defined digest in your component?
If not, you can do that as: digest: {}; at the component level.
I hope this helps you on your quest!
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 am using Runscope only for a short time now however it seems pretty straight forward. I have had no problem with other APIs, however for this current one I am having problems.
The error I am getting is the following:
Error contacting host SSL: certificate is valid for *.hostgator.com,
hostgator.com, not NflArrest.com To turn off SSL verification for
this test, change your test's behavior settings, see
https://www.runscope.com/docs/api-testing/behaviors for more details
From the documentation I read here:
SSL Certificate Verification
By default, Runscope will only relay responses if the SSL certificate from the upstream API provider is valid and trusted. To bypass this protection (for instance if you're using a self-signed certificate) on a per-bucket basis, select Bucket Settings in the left sidebar and deselect the option to 'Verify SSL Certificates'.
I have done that so to my knowledge it should work. However I still get the same error. The API documentation I am using can be found here.
Test's don't use the bucket setting, that's just for Gateway URLs/Traffic Inspector. To disable SSL verification in your test, expand the "Environment" section at the top of the test editor, select "Behaviors" and untoggle it there.
Whenever I try to add the following endpoint, "http://ws.cdyne.com/phoneverify/phoneverify.asmx", during the Managed API setup process and press the Test button I get an error on the server. ERROR - APIProviderHostObject Error occurred while connecting to backend : "stackOverflow preventing me from showing this link", reason: Connect to ws.cdyne.com:80 timed out
When I try this exact same process on a machine outside of our proxy it works fine. I have gone into the axis2.xml file and added proxy information and even went as far as installing cntlm and setting the proxy to localhost - same error.
I can browse to the above link just fine on this machine.
My environment is Windows 10.
I assume you talk about clicking the Test button when providing Backend Endpoint in API publisher.
The way that Test button works at the moment (as far as I understand) is that it invokes HTTP HEAD method on the endpoint provided (because according to RFC 2616, "This method is often used for testing hypertext links for validity, accessibility, and recent modification.")
Then it checks response. If response is valid or 405 (method not allowed), then the URL is marked as Valid.
Thus sometimes, if backend is not properly following RFC, you might get otherwise working URLs declared as Invalid during the test because of that improper HEAD response evaluation. Obviously, this is just a check for your convenience and you can ignore the check if you know the endpoint works for the methods and resources you need it to work.
So my advice would be to try ignoring the Test and just finishing setting up and publishing the API.
P.S. I am checking it on WSO2 API Cloud but behavior is identical to downloadable API Manager.
I am working through some samples in the ActiveMQ-Apollo installation and playing around with the examples/websocket.
In this file, Stomp.js is being used to establish connection:
client = Stomp.client(url);
The example works fine and I am able to see the messages being sent and received. The issue, is that Stomp uses default WebSocket which may not be available at times. So, I wanted to integrate with SockJS client library. According to the example for StompJS on this page (http://jmesnil.net/stomp-websocket/doc/) it should be possible with this code:
<script src="http://cdn.sockjs.org/sockjs-0.3.min.js"></script>
<script>
// use SockJS implementation instead of the browser's native implementation
var ws = new SockJS(url);
var client = Stomp.over(ws);
[...]
</script>
The above code appears to execute correctly, however, later I see the following errors:
XMLHttpRequest cannot load ws://mylocaldomain.com:61623/info. Cross origin requests are only supported for HTTP. sockjs-0.3.js:807
Uncaught Error: NetworkError: DOM Exception 19
Then, I see the debug window show this message:
Opening Web Socket...
Whoops! Lost connection to undefined
I am serving the page from mylocaldomain.com:80, and the ActiveMQ Apollo server is running on the same machine, but listening on port 61623. I have also grabbed the latest version of StompJS (from dist directory on github) as well as SockJS directly from cdn.sockjs.org.
I tried this example on latest Chrome and Firefox (on OSX) and the same thing occurs. No connection is established.
Again, going back to the standard example which ships with the Apollo works fine, but I would like to find out why StompJS over StockJS is failing.
Has anyone seen this issue?
Thanks.
-AP_
You need to modify the ActiveMQ-Apollo web configuration to support Cross-Origin-Resource-Sharing (CORS) as described here:
Enabling CORS
W3C CORS Specification
Basically the server needs to do the following things:
Support the HTTP OPTIONS request (aka CORS pre-flight request) that is sent by browsers for Cross Domain requests. This includes responding to the OPTIONS request with:
Access-Control-Allow-Origin header (for example: "*" which means allow all origins)
Access-Control-Request-Method header (for example: "GET, POST, PUT, DELETE, OPTIONS")
Access-Control-Allow-Headers (for example: "X-Requested-With,Origin,Content-Type, Accept")
The handling of HTTP OPTIONS can typically be done using a single Web Filter matching filter pattern "/*".
See also "cors_origin" WebSocket connector URL query parameter supported by ActiveMQ Apollo 1.7
While debugging, we observe following behavior:
1) When trying to get encryption key from server then error on both (iOS or Android) platform
response [https://xxxx.xxxx.com:443/worklight/apps/services/random]
success: Exception thrown by application class
'com.ibm.ws.webcontainer.session.impl.HttpSessionContextImpl.checkSecurity():685'
SESN0008E: A user authenticated as anonymous has
attempted to access a session owned by user:NewRealm/CN=test
user,OU=Temporary Users,OU=Acc,DC=xxxx,DC=com.
2) When trying to read a stored value error on android is [Logcat]
Android Message: Uncaught 9 at
file:///data/data/com.xxxx.xxxxapp/files/www/default/wlclient/js/encryptedcache.js:63
Where try to call WL.EncryptedCache.read
Worklight version used is 5.0.5 Consumer Edition (with Oracle 11i) on
Windows 2008 R2
WebSphere Liberty profile
Worklight server is sitting behind IBM Datapower XI52. All SSL calls to the server are going via DP.
Authenticator - WebSphereFormBasedAuthenticator & LoginModule - WASLTPAModule
The following is not really an answer, since I'm not familiar with authentication (LTPA, FormBasedAuth, Data Power, etc.)... just a couple of comments that could help you debug/isolate the issue.
Looks like a problem with authentication:
A user authenticated as anonymous has attempted to access a session
owned by user:NewRealm/CN=test user,OU=Temporary
Users,OU=Acc,DC=xxxx,DC=com.
Not with the Encrypted Offline Cache (EOC).
EOC will try to get a random token calling the following function:
WL.EncryptedCache.secureRandom(function (data) {
console.log(data);
});
It should output something like this:
response [/apps/services/random] success: 9053bdcfd902aac3dfb59a9874c9cf55223b7d17
9053bdcfd902aac3dfb59a9874c9cf55223b7d17
You can view the functions source code typing the following in a JS console:
WL.EncryptedCache.secureRandom
If you're using Google Chrome developer tools there's a checkbox for Log XMLHttpRequests when you click on the gear icon > General > Console.
You can also try to request the URL directly. Assuming the host is localhost, port is 10080 and project name is wlproj:
http://localhost:10080/wlproj/apps/services/random
9053bdcfd902aac3dfb59a9874c9cf55223b7d17
You can view HTTP traffic with Wireshark or Charles Proxy.
I imagine this will fix the EOC issue for you, if you don't mind generating the random token locally (less security, AFAIK):
WL.EncryptedCache.secureRandom = function(callback){callback(Math.random()+"")}
For example:
Notice it never goes to the server, everything is done locally.
A user authenticated as anonymous has attempted to access a session owned by user:NewRealm/CN=test user,OU=Temporary Users,OU=Acc,DC=xxxx,DC=com.
This usually means that there is a conflict with the session sent by the user (the session cookie) belongs to a user (in this case), but the LTPA token sent as a cookie was not sent or was not valid. There could be a few causes of this. This best way is to do a trace between datapower and the worklight server to make sure an LTPA token is even being sent to the worklight server. If it is, verify all of the LTPA requirements are met (synchronized time, same private key on both machines).