Why is my url being modified with my setup? - alamofire

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.

Related

Possible proxy issue with WSO2 API Manager

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.

POST /token 400 (Bad Request) with ember-cli and ember-simple-auth

I just setup the example from https://github.com/simplabs/ember-cli-simple-auth-example using Cloud9 and I get a 400 Bad Request error when I try to login.
I'm pretty sure this is due to fact that Cloud9 only opens port 80 (as referenced in this note from http://log.simplabs.com/post/90339547725/using-ember-simple-auth-with-ember-cli:
As the OAuth 2.0 authenticator would by default use the same domain
and port to send the authentication requests to that the Ember.js is
loaded from you need to configure it to use http://localhost:3000
instead.
Unfortunately I don't know how I might work around this. Any ideas?
Add the host to the whitelist in the config:
window.ENV['simple-auth'] = {
crossOriginWhitelist: ['http://some.other.domain:1234']
}
More info in the Cross Origin Authorization section of the docs

Using stomp.js over sock.js with ActiveMQ-Apollo does not seem to work

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

WCF over HTTPS in Monotouch?

I am trying to call a wcf service over https and have followed the suggested setup from here. It works fine over http, but I get a RemoteCertificateNameMismatch error over https which I am handling with this (as suggested) -
System.Net.ServicePointManager.ServerCertificateValidationCallback +=
(se, cert, chain, sslerror) => { return true; };
I later get a 415 unsupported media type error which I can't figure out. I have a win .net test client that is able to call the service and receive results, but from monotouch I can't get it to work. Has anyone been able to do this successfully and wouldn't mind pasting an example?
Any help is much appreciated!
HTTP error codes comes from the server side. Of course the client configuration may play a role into this.
If possible switch to HTTP and compare sessions (e.g. using wireshark) between your Windows's and MonoTouch clients. Doing so in HTTPS may tell you a few things but that's less likely to be helpful.
Also check for similars 415 errors affecting other (non-MonoTouch) projects. Since the error comes the server the information they provide might help you find what's going on.

DotNetOpenAuth RP fails behind SSL appliance

I'm having trouble getting a DNOA RP working behind an SSL appliance (terminates the client HTTPS connection and reverse-proxies HTTP to the webserver behind it).
The problem is that the RP is incorrectly guessing the recipient endpoint from the incoming request (since it's not HTTPS by the time it hits the webserver) and comparing the endpoint with scheme on the return_to url (which is HTTPS)- it fails with the stacktrace below. I've spelunked around in the code a bit and I don't see a way to change this behavior without a custom build or a non-trivial subclass. I'm already passing the HTTPS version of the Realm and ReturnToUrl to OpenIdRelyingParty.CreateRequests()- that part's working fine.
Is it possible to fudge the detected recipient scheme to HTTPS or skip scheme comparison on a stock DNOA build, or am I patching up a custom build tomorrow?
Stacktrace:
ERROR DotNetOpenAuth.Messaging - 09 Jul 2010 00:11:39,450 - Protocol error: The openid.return_to parameter (https://XXX/Login.aspx?openid=XXX&dnoa.userSuppliedIdentifier=XXX) does not match the actual URL (http://XXX/Login.aspx?openid=XXX&dnoa.userSuppliedIdentifier=XXX&openid.ns=http://specs.openid.net/auth/2.0&openid.mode=id_res&openid.op_endpoint=XXX&openid.response_nonce=XXX&openid.return_to=https://XXX/Login.aspx?openid=XXX&dnoa.userSuppliedIdentifier=XXX&openid.assoc_handle=XXX&openid.signed=op_endpoint,claimed_id,identity,return_to,response_nonce,assoc_handle&openid.sig=XXX&openid.identity=XXX&openid.claimed_id=XXX) the request was made with.
at DotNetOpenAuth.Messaging.ErrorUtilities.VerifyProtocol(Boolean condition, String message, Object[] args)
at DotNetOpenAuth.OpenId.Messages.IndirectSignedResponse.VerifyReturnToMatchesRecipient()
at DotNetOpenAuth.OpenId.Messages.IndirectSignedResponse.EnsureValidMessage()
at DotNetOpenAuth.Messaging.MessageSerializer.Deserialize(IDictionary`2 fields, MessageDictionary messageDictionary)
at DotNetOpenAuth.Messaging.Reflection.MessageDictionary.Deserialize(IDictionary`2 fields)
at DotNetOpenAuth.Messaging.Channel.Receive(Dictionary`2 fields, MessageReceivingEndpoint recipient)
at DotNetOpenAuth.Messaging.Channel.ReadFromRequestCore(HttpRequestInfo request)
at DotNetOpenAuth.Messaging.Channel.ReadFromRequest(HttpRequestInfo httpRequest)
at DotNetOpenAuth.OpenId.RelyingParty.OpenIdRelyingParty.GetResponse(HttpRequestInfo httpRequestInfo)
at DotNetOpenAuth.OpenId.RelyingParty.OpenIdRelyingParty.GetResponse()
DotNetOpenAuth has built-in support for SSL appliances when they add these special HTTP headers to the forwarded HTTP request: X_FORWARDED_PROTO and/or HTTP_HOST. When these are present, the auto-detection of the outside-facing URL is correct. If you can configure your SSL appliance to do this, that's probably the best option.
The alternative is to call OpenIdRelyingParty.GetResponse(HttpRequestInfo) instead of the overload that takes no parameters. You construct the HttpRequestInfo yourself using the outward-facing URL that you know is the real one. Then the URL matching logic inside DotNetOpenAuth won't fail the request.