Dropbox OAuth callback to Mule using https - oauth

Dropbox requires the callback URL to be over HTTPS (when not using localhost).
Using Mule 3.6.0 with the latest dropbox connector, the callback defaults to http - thus only working with localhost. For production I need to use https for the OAuth dance.
What is the correct way to specify a https callback URL?
I've tried:
<https:connector name="connector.http.mule.default">
<https:tls-key-store path="${ssl.certfile}" keyPassword="${ssl.keyPass}" storePassword="${ssl.storePass}"/>
</https:connector>
<dropbox:config name="Dropbox" appKey="${dropbox.appKey}" appSecret="${dropbox.appSecret}" doc:name="Dropbox">
<dropbox:oauth-callback-config domain="production.mydomain.com" path="callback" />
</dropbox:config>
But it errors:
Endpoint scheme must be compatible with the connector scheme. Connector is: "https", endpoint is "http://production.mydomain.com:8052/callback"

Here's what I ended up with that solved the problem:
<https:connector name="connector.http.mule.default" doc:name="HTTP-HTTPS">
<https:tls-key-store path="${ssl.certfile}" keyPassword="${ssl.keyPass}" storePassword="${ssl.storePass}"/>
</https:connector>
<dropbox:config name="Dropbox" appKey="${dropbox.appKey}" appSecret="${dropbox.appSecret}" doc:name="Dropbox">
<dropbox:oauth-callback-config domain="myserver.domain.com" path="callback" connector-ref="connector.http.mule.default" localPort="8052" remotePort="8052"/>
</dropbox:config>
This works great for localhost, but not if you need the callback to go to something other than localhost (e.g. myserver.domain.com)
Reviewing mule.log you can see that the connector binds to localhost (127.0.0.0) despite the config pointing to:
domain="myserver.domain.com"
Log Entry:
INFO ... Attempting to register service with name: Mule.Ops:type=Endpoint,service="DynamicFlow-https://localhost:8052/callback",connector=connector.http.mule.default,name="endpoint.https.localhost.8052.callback"
INFO ... Registered Endpoint Service with name: Mule.Ops:type=Endpoint,service="DynamicFlow-https://localhost:8052/callback",connector=connector.http.mule.default,name="endpoint.https.localhost.8052.callback"
INFO ... Registered Connector Service with name Mule.Ops:type=Connector,name="connector.http.mule.default.1"
The workaround is to force Mule to listen to 0.0.0.0 for connectors which define localhost as the endpoint.
In wrapper.conf set
wrapper.java.additional.x=-Dmule.tcp.bindlocalhosttoalllocalinterfaces=TRUE

Related

How to get URL of OData service from SAP Gateway for connecting it with Web IDE Personal Edition?

I'm trying to connect SAP Web IDE Personal Edition" (local Web IDE) following this tutorial:
https://help.sap.com/viewer/825270ffffe74d9f988a0f0066ad59f0/CF/en-US/2cf47f37e34c428c97a51057733c0394.html
But no connection happens. I guess the problem is in the host URL and the port. How can I get the URL? I tried using S4HANA URL but it didn't work. Also tried Fiori URL didn't work either.
How to get the Gateway URL and port?
If you have an on-premise system, then call /N/IWFND/MAINT_SERVICE, choose your service, click on Gateway Client, set the protocol to HTTPS and you'll see the full URL. If you don't then HTTPS isn't configured for your system --> call SMICM, Goto (from menu), Services and check the Host and Port columns in HTTP row. That's your host and port.

Why does Apereo CAS server redirect to localhost for OAuth2 endpoint?

I have setup a CAS server at 172.16.238.10 that generally works with the CAS protocol. However, for OAuth2 there is a strange redirection behavior:
REQ: https://172.16.238.10:8443/ooscas/oauth2.0/authorize
RESP: 302, Location: https://localhost:8443/ooscas/login?service=https%3A%2F%2Flocalhost%3A8443%2Fooscas%2Foauth2.0%2FcallbackAuthorize%3Fclient_name%3DCasOAuthClient
Never mind the service and client_name parameters for this staged example, but my question is about the hostname:
Where does the "localhost" come from? How can I configure that to be something else?
In a real OAuth2 webflow localhost will simply not work, even if 172.16.238.10 happens to be localhost. The reason is that by posting the login form to localhost, the CAS server then redirects to itself using localhost (https://localhost:8443/oauth2.0/callbackAuthorize) and that will lead to an internal SSL handshake error, because the server's certificate is not valid for localhost.
Most likely, you need to define the following:
cas.server.name=
cas.server.prefix=${cas.server.name}/cas
You're referencing the prefix in your setup, but its definition seems absent. If you fail to do that, default values take place.
PS Always specify the CAS version in your posts.

Testing Twilio with ngrok tunnel to localhost results in bad host name error

In the past I've used ngrok to test twilio webhooks on my local machine - it's always worked. I'm working on a new app that uses Co-Pilot (not sure if it has anything to do with co-pilot) and I'm getting the 11210 error: HTTP bad host name.
I initialize my tunnel with /Applications/ngrok http -host-header=rewrite local.whicheversiteimworkingon.com:80
The URL listed in the Message Text is http://fcd0ed57.ngrok.io/sms/twilio/incoming but the body shows
Twilio was unable to fetch content from: https://local.thesiteimworkingon.com/sms/twilio/incoming
Error: Unknown host local.thesiteimworkingon.com
Account SID: AC5a22f090b458f6942da879d347451dfd
SID: SM9c45741b5b70967df6a7e196e3bee552
Request ID: 9fde222c-14e1-448e-ad79-4a392d212ffd
Remote Host: local.thesiteimworkingon.com
Request Method: POST
Request URI: https://local.thesiteimworkingon.com/sms/twilio/incoming
SSL Version: TLSv1.2
URL Fragment: true
Unfortunately I don't have an example of this from when it was working - it's been months (maybe 12+) since I've had to do this.
[Update] I've confirmed this happens with co-pilot and regular numbers, starting to think it's environment related.
Have I misconfigured something in order to test this locally?
Can you try the https ngrok instead of http?
Twilio developer evangelist here.
It may be to do with the application server you are using expecting a different host name. When you start Ngrok, you can pass the --host-header flag to rewrite the host header for your application.
ngrok http 3000 --host-header=rewrite local.domain.com
Let me know if that helps at all.

How to setup HAProxy to add access token to client requests

I have a client that can only make requests without authentication information.
I would like to use HAProxy or a similar proxy solution to add OAuth authentication to these client requests.
I already succeeded to add a Bearer token to the client requests. See below for the haproxy.cfg with some placeholders.
frontend front
mode http
bind *:8080
default_backend servers
http-request add-header Authorization "Bearer {{ .Env.ACCESS_TOKEN}}"
backend servers
mode http
server server1 myserver.com:443 ssl
The problem is that the access tokens have a TTL of 24 hours. So I need to refresh them or get a new token periodically.
Does HAProxy support this already?
I can write some script to get a new access token periodically, update the config and restart HAProxy. Is this a good approach when running HAProxy in docker? Are there better solutions?
You could give a try to create/test your script using Lua, it is now supported in the latest versions, check How Lua runs in HAProxy.
An example of this but using Nginx + Lua, can be found in this project: https://github.com/jirutka/ngx-oauth

How set cookie sent from server to a client on a different port

I have a backend server (powered by Rails), whose APIs are used by a HTML5 frontend that runs on a Node simple development server.
Both are on the same host: my machine.
When I login from the frontend to the backend, rails sent me the session cookie. I can see it in the response headers, the problem is that browsers do not save it.
Policies are right, If I serve the same frontend directly from the rails app cookies are set right.
The only difference I can see is that when the frontend run on Node server, It runs on the port 8080 and rails is on the port 3000. I knew that cookies are not supposed to be port specific, so I am missing what is happening here.
Any thoughts? solutions?
(I need to be able to keep the setup this way, so to have the frontend served from Node and the backend on rails on different ports)
You're correct that cookies are port agnostic, and that the browser will send the same cookies to myapp.local:3000 as myapp.local:8080--except not through XMLHttpRequest (XHR, a.k.a., AJAX) when doing a cross-site request (CORS).
Solution: The request can be told to include cookies and auth headers by setting withCredentials to true on any XMLHttpRequest object. See: https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials
Or if using the Fetch API, set the option credentials: 'include'. See: https://developer.mozilla.org/en-US/docs/Web/API/Fetch_API/Using_Fetch
Alternative: since you tagged webpack-dev-server in your question, you might be interested in proxying requests to your Rails API through the webpack-dev-server to avoid any CORS issues in the first place. This is done in your weback.config:
proxy: {
'/some/path': {
target: 'https://other-server.example.com',
secure: false
}
}
See: https://webpack.js.org/configuration/dev-server/#devserverproxy

Resources