IBM Worklight - Application Center Console - Redirection to port 9080 - ibm-mobilefirst

We are trying to setup the Worklight Server for production, which is behind a reverse proxy that will help manage the SSL certificate.
What this means is that, when the user hit the domain, say https://mydomain.com:443, the proxy will automatically forward the request to the Worklight Server on port 9080.
After the setup is done for the reverse proxy following this guide, the installers.html page is working well. However we notice that when we try to access the console using https://mydomain.com:443/appcenterconsole, the user gets redirect to http://mydomain.com:9080/appcenterconsole/console.html instead and this is causing problem.
I searched around and found this link Worklight Console redirects to port 9080, which is similar to the problem i'm having. Is there a way for me to configure the Websphere Liberty Profile so that it will use the reverse proxy URL as the redirection URL?
I notice also that the index.html file in the appcenterconsole.war is using the meta refresh method to do the redirection. I'm tempted to change it to use a full URL, but then i also notice that the same issue happens when we go to the login.html and perform login. (Whereby after login, the page redirects the user with the 9080 port as well).
Any pointers or idea are welcomes. The Worklight version used is 6.1.
Thank you.
EDIT
The network setup in my environment:
Proxy Gateway (with SSL cert) configured to connect to Worklight Server for port 9080 whenever a connection with port 80 or 443 is received. Therefore:
https://mydomain.com:443/appcenterconsole -> will be mapped to http://worklightserver:9080/appcenterconsole
The mapping is done internally between the proxy and the worklight server.
When we type the full URL on the browser, ie. https://mydomain.com:443/appcenterconsole/console.html after i login, the console works fine.

Have you set up the JNDI entries detailed here?
http://pic.dhe.ibm.com/infocenter/wrklight/v6r1m0/index.jsp?topic=%2Fcom.ibm.worklight.installconfig.doc%2Fappcenter%2Fr_ac_appres_endpoint.html

Related

MITM Proxy - How to intercept user requests in reverse proxy mode from inside/outside Web Application Server

I am new to mitm.
https://mitmproxy.org/
AppServer1 (A windows 2016 server) has our IIS website application (WebApp1) running (its running fine without any problems currently).
I have added an SSL certificate as well, and it is loading fine without any issues.Chrome shows that it is trusted ("Connection is secure" when navigating from inside and outside AppServer1 server but "within the LAN". So far we havnt allowed access to internet users as of yet until the app is completely ready.)
We have a business requirement where
we need to intercept all traffic/requests from users from outide AppServer1
and send them to another application that we created (UserRequestDashboardApp),
and ALSO we need mitm to send it to WebApp1 as well.
I have read the articles multiple times and from what I understand, reverse proxy mode is the correct option to for our requirement.
WebApp1 is running on url - customappservice1.com, port - 443
I then started mitm (version 4.0.4) with the following CMD command
.\mitmdump -p 8080 --mode reverse:https://customappservice1.com
I get the status proxy server listening at http://*:8080
I dont seem to see any traffic in the terminal when I type customappservice1.com on AppServer1 chrome browser or any server browser outside AppServer1.
The WebApp1 pages load fine from outside and inside AppServer1 server but no traffic at all on the terminal
Can anyone please help me to capture the traffic on the terminal as an initial step before sending the traffic/requests to UserRequestDashboardApp AND WebApp1?
I have tried running mitm normally and it works fine(I can see traffic/requests fine in the terminal)
I launched mitm in CMD (It says Proxy Server listening at http://*:8080)
I set the
Windows server proxy to = localhost
Port = 8080
Did you try configuring your requests to use the mitmproxy's address ?
Also, web browsers may have use a separate proxy configuration from the operating system's. So you may try configuring Chrome's proxy settings.

How to make browsers trust a local network wss:// connection?

I'm trying to upgrade a websocket connection ws:// to wss:// using a nginx reverse proxy https://github.com/nicokaiser/nginx-websocket-proxy/blob/master/simple-wss.conf
but I seem to be having trouble with the certificate part. My server is located on the same network as the client. So Ideally I would want my users to log in to "https://example.com" and then the client makes a connection to "wss://192.168.1.xxx:xxxx".
As of now the browsers are blocking it because of NET::ERR_CERT_COMMON_NAME_INVALID. I don't really know to produce a self signed certificate that the browsers will trust on the local network. Googling only gives me answers on how to do it if my server would be accessed using a domain name but I will always connect to a local network IP. Help is appreciated!
To anyone coming across this I managed to solve it using this post outlining the architecture https://support.plex.tv/articles/206225077-how-to-use-secure-server-connections/
What ended up happening was that we set up a url pointing to a server running nginx which parsed the subdomain and redirected the connection to that url. For example: wss://192-168-1-142.mydomain.com redirects to ws://192.168.1.142 which makes the browser trust the connection
Does this work?
Your post is a year old now and browsers have become stricter since then. Usually, a browser will produce 'mixed content' errors if you access HTTP content from a HTTPS page, and the only way to get round this is to change the site settings to allow insecure content, which is scary for users in the face of a big warning message.
If accessing an HTTPS web address redirects to an HTTP local IP address, won't the browser still complain about mixed content?
I have a similar situation to you. I am writing a Progressive Web Application (PWA) to control network music players on a home network. The players only support HTTP but a PWA requires HTTPS for services workers to work and to allow the app to be 'installed'.
My solution is to run a local server on the home network which can talk to the players over HTTP. Then I can access this server over HTTPS from my browser so that the browser itself is not making any HTTP calls.
This works fine if the server is on localhost because localhost is a special case where security rules are relaxed. But if the server is on another machine, how can I create an SSL certificate since (1) it seems that local IP addresses are not allowed in the Subject Alternative Name (SAN) section of the certificate, and (2) I won't know in advance what the IP address of the server will be.
If your workaround works, then the local server can use HTTP instead so I won't need a certificate. The local server can register itself with a web server, and then the browser can connect over HTTPS to the web server, which would redirect to the IP address of the local server over HTTP.
But does this trick work?

How to debug https setup?

I use my home network (ATT U-Verse) to serve my ASP .NET website on a Windows 8.1 Pro machine with IIS 8.5. Because Chrome requires https for doing audio recording, I want to move to https. I followed the instruction video at https://www.netometer.com/blog/?p=1758 , and everything corresponds (IIS showing that I have a certificate in the bindings and an entry for port 443) until I test the actual https link in a browser (on the server itself, on an other machine on the home network, or externally via my phone with data), which gives me a "This page can’t be displayed" or equivalent message. I added port 443 to the Norton firewall rule I already had. The http access still works, however. Netmon 3.4 shows no TLS or SSL traffic. I also tried disabling the Norton firewall temporarily. This leads me to believe that the problem is that either the ATT NVG510 router I have is blocking port 443, or that ATT itself is blocking it. Looking at the router settings on the Packet Filter page, it seems none of the default "Drop" rules are enabled, and there is an "Enable Packet Filters" button. Do I specifically have to set up a "Pass" rule?
Does anyone have any ideas on what I could do? Can I actually do https on my home server? My web site is www.jtlanguage.com . Sorry if this is the wrong place to put this. I'm a programmer trying to do some IT.
Thanks.
-John
Turns out I wasn't doing port forwarding. For NVG510 users this is done by going to the router page in the browser to firewall->NAT/Gaming page and adding a hosted application referencing the HTTPS service and the web server machine name.

How do I force users to access my Play application through SSL?

I have a Play application that I've deployed by running stage within SBT, and then running it from the command line using target/start. I've placed Nginx in front of it and, based on a sub-domain, I have two server blocks--one for port 80, and the other for port 443. The port 80 block just redirects to the https scheme on port 443. This all works great.
To recap:
http://play.mydomain.com/ redirects to
https://play.mydomain.com/ which is a proxy for http://localhost:9000
However, if I just go to http://mydomain.com:9000/, I get access to my Play application directly. There's no SSL, and there's no way I can figure out to keep anyone from accessing it.
What should I do? Should I use Nginx to redirect any access on port 9000 to the URL for the SSL version? Should I firewall port 9000 and only allow local requests on that port? (If so, how would I do that?) Is there some other way of dealing with this that I'm not thinking of?
And how long until the Servlet 3.1 spec is released and I can just deploy the whole thing as a WAR? :-)
You could make your Play application listen only on the local interface (127.0.0.1, for example). That way, nginx can still proxy requests to it but nobody from the outside can access your application directly. No additional firewall setup is necessary.
Looks like you can pass an additional argument to start:
$ start -Dhttp.port=9000 -Dhttp.address=127.0.0.1

https stops working after site publish

I am working on Windows Server 2003 (IIS6), which has two asp.net sites running in seperate app pools. One of the sites has an ssl certificate installed and was running fine on https. The other site has no certificate and does not require https
The problem I have is that when I publish my app from vs2005 to the site with ssl the https urls stop working and I can only use http. The error I get is as follows
From Google Chrome: Error 104 (net::ERR_CONNECTION_FAILED): The attempt to connect to the server failed.
From IE7: Internet explorer cannot display the web page, could be unavailable, dns is not reachable etc
The strange thing is the first time this happened, https eventually became available but I don't know what triggered the availability but when I published an updated assembly to the bin folder of the site which does not require https, the OTHER site became unavailable on https again
Help much appreciated!
UPDATED: Thanks for the suggestions but it turns out that the firewall was not open on the ssl port
Check if the firewall port for SSL (443) wasn't accidentally closed 443. ;-)
If both webs use the same IP address, make sure, that only the web with the certificate uses the SSL port 443 (first property page). The input field should be empty for the insecure site.
If that is not the problem, you could try to debug stopping the web without certificate and restart the web server.