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.
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.
This is essentially a duplicate of Can not add account for custom Sonos service, but there's no accepted answer and I am not able to add a comment to ask if they ever resolved their issue.
I've inherited a project and am trying to add the development service. I've configured it via /customsd.htm, set the header policy to Session ID, have both secure and insecure endpoints working.
When I go to add the channel, I see the request for strings.xml. However, I never see any requests come in for getSessionId. Meanwhile the SONOS reports "Account Not Found. ***** server did not recognize your login information." I am able to make the request with SoapUI, and I get a valid response.
If it's worth mentioning, I am in SONOS' beta program and am on version 6.2, build 31926010 (Mac desktop app).
UPDATE:
While I'm not sure there's anything useful here, looking at logs at [deviceIP]:1400/support/aggregate, I see the following. Note that the redacted URL and IP do resolve. IP is for a loadbalancer, URL is behind it.
Feb 28 11:07:42 Sonos[84168] <![CDATA[<]]>Error<![CDATA[>]]>: (SCLib) dns(1): [redacted URL] -<![CDATA[>]]> [redacted IP]
Feb 28 11:07:42 Sonos[84168] <![CDATA[<]]>Error<![CDATA[>]]>: (SCLib) control_client(1): getSessionId failed, res = 1000, tvStart = 1456679262 s 250163 us, m_tvConnectDone = 1456679282 s 250162 us, m_tvDone = 1456679302 s 250162 us, tvNow = 1456679262 s 509982 us
Feb 28 11:07:42 Sonos[84168] <![CDATA[<]]>Error<![CDATA[>]]>: (SCLib) soap(1): - param username = [redacted username]
UPDATE #2:
I inspected the packets via Wireshark, and behavior of the production service and development one seem the same except that for the production service, the controller / my computer kicks off a POST request to the Sonos before the server hangs up. That process, outlined in red in the attached image, does not occur for the customsd service.
I also experimented with using the production service endpoints in the customsd configuration, but that request failed in the same manner. FWIW, all ssl_validation tests pass just fine, as do various content tests.
For want of a trailing slash...
I finally sorted this, and it was incredibly minor. In the customsd configuration, my endpoint urls did not have a trailing slash. Adding them made it all work.
I finally realized this when I decrypted the calls the controller made to the server for both the production service and my customsd service registered to the production endpoints. The call made by the customsd service was getting back the load balancer's 400 error. The only difference between the calls were the headers, specifically:
Production service: POST / HTTP/1.1
Dev service : POST HTTP/1.1
LB properly said the call was invalid. Adding the trailing slash made it all work.
For what it's worth, I'm pretty sure the URLs without trailing slashes worked both via curl and, I believe, via SoapUI. The Sonos controller requires them, however.
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.
While I was reading about interaction with Amazon S3, I came to know that request authentication with Amazon AWS is done in 2 ways
HTTP Authorization:
Using the HTTP Authorization header is the most common method of providing authentication information
Query string parameters:
Using query parameters to authenticate requests is useful when you want to express a request entirely in a URL. This method is also referred as presigning a URL.
The question is in which situation should I prefer one method over the other. Do these two authentication methods have their own advantages and disadvantages? As a developer, by using query string parameters method I can presign the URL which enables the end users to temporarily access the Amazon S3 resources by entering the presigned URL in the web browser. Can I use HTTP Authorization method to achieve the same thing? If so which method is better to use and what are their respective limitations?
Can I use HTTP Authorization method to achieve the same thing?
Sometimes. The key difference is that, as a developer, you don't always have enough control over the user agent to inject a header. The most obvious example of this is a simple GET request launched by a web browser in response to the user clicking a link. In that situation, you don't have the a ability to inject an Authorization: header for the browser to send ... so pre-signing the URL is all you can do.
Importantly, there's no information in a signed URL that is considered sensitive, so there's no particularly strong motivation to use the header instead of a signed URL. Your AWS Access Key ID is not secret, and your AWS Secret can't be derived from the other elements and the signature in a computationally-feasible time frame, particularly if you use Signature Version 4, which you should. Signature Version 2 is not officially deprecated in older regions, but newer S3 never supported it and likely never will.
When you do control the user agent, such as in back-end server code, adding the header may be preferable, because you don't need to do any manipulation of the URL string you already have in-hand.
The overview in the first AWS page says what the difference is:
Except for POST requests and requests that are signed by using query parameters, all Amazon S3 bucket operations and object operations use the Authorization request header to provide authentication information.
Basically a POST is used for HTML forms (discussed at length in the Mozilla page). You would use forms whenever the request involves passing data to the remote server, versus just checking status. As noted in HTML method Attribute (W3Schools),
Never use GET to send sensitive data! (will be visible in the URL)
as distinguished from POST:
Appends form-data inside the body of the HTTP request (data is not shown is in URL)
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.