Parse-server SSL IIS - rest

I have tried using serverURL as localhost:1337/parse and publicServerURL as https://mydomaindotcom:1337/parse but I don't know how parse is recognizing the certificate. I don't see a config value to set the cert for parse-server.
Also tried adding cert to IIS 7 to a website on port 443 and using URL Rewrite 2.0 to localhost:1337/parse.
I'm running a self-hosted parse instance using node. parse-server is installed globally. I'm using a config file to start to instance.
Server works fine on http, however I need to utilize https so I can use the rest or js api key without passing headers like so https://myAppID:javascript-key=myJavaScriptKey#mydomaindotcom/classes/GameScore/Ed1nuqPvcm
Any help is much appreciated.

You need to add an https binding that references port 1337 if that is the one that you want to use.

Related

Sending HTTP via proxy with haproxy

We have a company proxy (ip:port) and need to send HTTP POST with json payload to the URL like "http://server1.smthng.com/foo". Locally, name could not be resolved, but it is resolved at proxy. I dont understand how to configure haproxy to use proxy "ip:port" and send request without modifying the original URL.
I've tried curl to "http://server1.smthng.com/foo" after setting https_proxy variable from CLI (in linux) and it worked for me, so now I need to replicate same via haproxy.
From curl logs I could see that it first makes a CONNECT to proxy and once connection is there it POSTs the data.
I could be missing some knowledge here regarding tcp tunnels and the answer could be simple really. Anyway, need help.
The question is to be closed with no asnwer. The solution we took is via civetweb htt_proxy parameters.

Advanced Tweak on Undertow-handlers.conf for http https redirect

I use WildFly behind an AWS load balancer. I want the Undertow server in WildFly to redirect http traffic to https, and I can do this mostly successfully with the following line placed in undertow-handlers.conf:
equals('http', %{i,X-Forwarded-Proto}) -> redirect(https://app.server.com%U)
Thanks to these folks for getting me this far! Now here's my desired tweak. Sometimes I run my web application behind a testing load balancer using 'dev.server.com' and sometimes I run it behind a production load balancer using 'app.server.com.' Currently, I have to remember to manually edit undertow-handlers.conf any time I switch balancers. I'm hoping there is a way to change the hard-coded 'dev' and 'app' to something mechanical. Is there a way to tell Undertow to just use the domain name that was originally requested?
Thanks.
Thankfully the undertow configuration gives you access to the request headers via Exchange Attributes, which you're already using to access the X-Forwarded-Proto header. So the solution is to simply use the Host header from the request like so:
equals('http', %{i,X-Forwarded-Proto}) -> redirect(https://%{i,Host}%U)
If you want to keep it as part of the deployment try using the %h in the redirect expressions. For example:
equals('http', %{i,X-Forwarded-Proto}) -> redirect(https://%h%U)
Another option would be to configure the server to handle the redirect for you. The CLI commands would look something like the following assuming the default ports of 8080 for http and 8443 for https.
/subsystem=undertow/configuration=filter/rewrite=http-to-https:add(redirect=true, target="https://%h:8443%U")
/subsystem=undertow/server=default-server/host=default-host/filter-ref=http-to-https:add(predicate="equals(%p, 8080)")
You can see all the possible exchange attributes in the Undertow documentation.

WS Federation (single sign on) module - redirect issue when using SSL offloading

We have a site that we are trying to configure as a client in a SSO scenario, using WS Federation and SAML.
Our site sits behind a load balancer that is doing SSL offloading - the connection to the balancer is under https, but decrypted and forwarded (internally) to the actual site under http and port 81.
Somewhere the WS federation module is attempting to redirect us, but is building up the URL based on the port and incoming protocol to the website:
We request:
https://www.contoso.com/application
and are getting redirected to:
http://www.contoso.com:81/Application
Which doesn't work as the load balancer (correctly) won't respond on this port.
And it seems to be related to the casing of the virtual directory. Browsing to
https://www.contoso.com/Application
seems to work without issue.
(Note for completeness, attempting to browse to http://www.contoso.com/Application with no port will correctly redirect us to the SSL secured URL).
I am trying to find out:
a) Where this redirect is happening in the pipeline and
b) How to configure it to use the correct external address.
If anybody is able to point me in the right direction, I would very much appreciate it.
EDIT 14:19: Seems to be either the WsFederationAuthenticationModule or the SessionAuthenticationModule. These do a case sensitive comparison of the incoming url to what it expects and redirects otherwise:
https://brockallen.com/2013/02/08/beware-wif-session-authentication-module-sam-redirects-and-webapi-services-in-the-same-application/
So that seems to be happening, its a matter now of trying to get the site to behave nicely and redirect to the correct external url.
The following seems to be related and ultimately points to the culprit in the default CookieHandler:
Windows Identity Foundation and Port Forwarding
Looking at that code decompiled in VS, it compares HttpContext.Current.Request.Url against the targetUrl and will redirect to the expected 'cased' version otherwise (in our case including the errant port number).
It would seem that explicitly setting the path attribute of the cookie fixes this issue. Either an empty string or the virtual directory name seems to work:
<federationConfiguration>
<cookieHandler requireSsl="true" name="ContosoAuth" path="/Application/"/>
<wsFederation passiveRedirectEnabled="true" issuer="https://adfsSite" realm="https://www.contoso.com/Application/" reply="https://www.contoso.com/Application/Home" requireHttps="true"/>
</federationConfiguration>

How to use Fiddler in C# with a proxy?

I've been using Fiddler in C#.
So far I'm able to intercept requests. However, I need to set a proxy. I did so, the proxy is set.
In Proxy Settings Windows' form, I have for HTTP and Secure: 127.0.0.1 for Proxy address to use and for the Port, 8888.
This is the same that is done when I use Fiddler application directly.
However, when I set it through my C# code, instead of using Fiddler, I can't navigate. My pages give me the message:
Your connection is not secure
What more do I need to do? What Fiddler do that I'm missing to correctly set a proxy?
Usually if it cant make a secure connection, you need to trust Fiddler's root certificate on your development PC. If you are using Firefox you will have to do an additional step to trust the certificate inside FF.

Azure Websites: socket reading port 80 returns 404 error

I have a php script that run perfectly when requested by the browser (example):
http://www.kwiksher.com/k3Serial.php?key="XXXXX"
in this case, I get the information of an user with the key XXXXX, which is the expected behavior.
However, inside my Photoshop plugin, I must to call it via socket, having to force a port in the connection:
http://www.kwiksher.com:80/k3Serial.php?key="XXXXX"
Doing that, I get the the content of Azure default 404 page (it is not even my customized 404 page).
If I use the same call (with the port added to the domain) on a browser, it works fine as well.
Any idea on how to fix it? I tried to flushDNS on my machine as well without success.
Thanks a lot,
Alex
It's likely that the socket library won't be using HTTP and therefore isn't sending a host header and the web tier on Azure can't actually figure out which Website it should serve the content from.
As you using this with a plug-in perhaps try and use the default hostname issued by Azure instead of a custom domain.