Does enable-basic-auth actually work in the keycloak-tomcat-adapter? - tomcat8

I'm trying to get the tomcat8-keycloak-adapter to accept basic auth as specified in the documentation, by setting enable-basic-auth to true. Instead of working or failing, as expected, this causes the thread to hang until HTTP times out.
Using tcpdump to snoop the HTTP connection between the tomcat adapter and the keycloak server shows that it is never sending the HTTP request. I can find no information about this on the internet, so I am down to the actual point of asking: does "enable-basic-auth" actually work in the tomcat adapter?
Note that I am using keycloak v1.9.8 and matching adpater 1.9.8. adaptever v2.0.0 appears to have difficulty starting up at this time, and we are still using the 1.9 keycloak in production. keycloak is the official docker image, tomcat is manually installed into the official tomcat8 docker image, using jre8.

It works for me in a Jetty setup. A hanging request indicates a networking problem to me. You question indicates that you are using docker.
The Tomcat inside its docker container needs to contact Keycloak as configured by the URL auth-server-url in the file keycloak.json.
I suspect that the Tomcat can't reach this URL. Please try to reach the URL as stated in keycloak.json from within the Tomcat's docker container, for example via curl --verbose ...

Related

Session is lost in apache after nginx proxy switch

I am building a docker which i can use for my work. I am using MacOS. If I create docker container with xdebug installed (Ubuntu 16, php7.2, xdebug, apache), code execution is extremely slow even if i am not listening to xdebug port. I have already get rid of 'mounts'.
So I decided to created something like this:
docker structure
And everything works just like i want. When i change cookie in browser, my wesbite works fast, but when i change cookie to another one, i am able to debug. But i am facing a problem that it logs out me when i change that cookie value and nginx proxies me to another server. (Each apache is a single docker container with ubuntu and apache)
So my question is if there is a workaround for this so I could share session between server that I don't get logged out? Or at least any ideas what needs to be changed in that scheme.
P.S. My project is Magento 2 and probably the source of an issue is in this one. But i actually don't think so.
According to https://www.nginx.com/products/nginx/load-balancing/, the sticky session is a feature of nginx plus.

liferay SSL port redirecting without port number

I am facing a problem trying to setup SSL for Liferay which seems straight forward but I am not able to crack it.
I am using Liferay 6.2 with MySQL 5.5 and trying to setup SSL on the server.
As I am experimenting I have followed http://java.dzone.com/articles/setting-ssl-tomcat-5-minutes (other sites too giving similar suggestions)
Now I am able to see the login page with https:liferay001:8443 and when I login the redirected url loses the port number and no page is shown after that(https://liferay001/web/guest/welcome?p_p_auth=PlbcFdOI&p_p_id=49&p_p_lifecycle=1&p_p_state=normal&p_p_mode=view&_49_struts_action=%2Fmy_sites%2Fview&_49_groupId=10204&_49_privateLayout=false)
But if I login via non SSL ie. liferay001:8080 the logged in page come in fine. I checked via developer tool and the 8080 is not losing the port when showing the :8080/web/guest/welcome?
I tried to login via 8080 port and then switch to 8443(SSL) port and the page shows up in SSL without issues.
So any navigation from SSL is making the port to be lost in url.
I have tried this in Windows and Ubuntu and both are showing the same behavior.
Is there changes I have to make on the Liferay side to get this running? I am not able to figure out which file changes I have to do along with server.xml.
Right now I am using .keystore in the server.xml file and not using anything complicated.
I have also experimented by adding the following to the portal-ext.properties
company.security.auth.requires.https=true
session.enable.phishing.protection=false
web.server.protocol=https
This has caused the server to not return any response now ie no login page as response too.
Posting the answer as there will be folks who will be not able to proceed without this knowledge.
I have tried to engage few folks in my team and all of them came to the same point where they could not proceed.
the answer is to have all the following entries in your portal-ext.properties
company.security.auth.requires.https=true
session.enable.phishing.protection=false
web.server.protocol=https
web.server.https.port=8443

Changing the localhost to a custom url in Jboss

I am trying to create a login module that could use facebook login too . I am using Jboss 7.1 as my server and i run it from inside eclipse and my OS is Ubuntu.
The problem now is that Facebook doesn't seem to accept requests when the url is of type say
http://localhost:8080/myApp/
and expects something of the form http://localhost.test/myApp.
(Testing facebook connect on localhost)
My problem is that I am not aware of how to change the above pattern (from localhost:8080 to say localhost.mysite) in JBOSS server.
Can someone let me know on how this has to be done.
Thanks
You can use the -b parameter to specify the bind address JBoss should use, see:
https://docs.jboss.org/author/display/AS71/Admin+Guide?_sscc=t
This switch should be available in the Eclipse JBoss Tools as well.
I discovered just recently that JBoss 7.x (as well as JBoss EAP 6) does not accept connections from outside if you don't specify the Host/IP-Address via the aforementioned parameter; even responses to web service requests it sends itself are not received.
If you want to change things like the web service endpoint host, port etc. you can do this via standalone.xml. For Web Services or ReST you simply specify subsections whose schema is defined by the XSDs located in the docs/schema folder (jboss-as-webservices_1_1, jboss-as-jaxrs_1_0 respectively ). For convenience (auto-completion, validation) you can put them into an XML catalog and registered the catalog within Eclipse.

Pushing my Mercurial Repository through HTTP with Apache and Windows

So I have managed it. I can clone mercurial-repositories remotely using HTTP to my Windows Server 2003 machine and the ipaddress from that machine. Although I did deactivate IIS6 and am using Apache 2.2.x now. But not all works right now...darn! Here's the thing:
Cloning goes smooth! But when I want to push my changes to the original repository I get the message "cannot lock static http-repository". On the internet I get to read several explanations that Mercurial wasn't designed to push over HTTP connections. Still, on the Mercurial website there's something about configuring an hgrc file.
There's also the possibilty to configure Apache to host via HTTPS (or SSL). For this you have to load the module enabling OpenSSL and generating keys.
Configuring the hgrc file
Just add "push_ssl = false" under the [web] line. But where to put this file when pushing your changes back?! Because I placed it in the root of the server, in the ".hg" directory, nothing works.
Using SSL/HTTPS with Apache
When I try to access 'https://myipaddress' it fails, displaying a dutch message which would mean something like "server taking too long to respond". Trying to push also gives me a dutch error message which means about the same. It can not connect to my server via https although I followed the steps exactly at this blog.
I don't care which of the above solutions will work for me. Turns out none of them work so far. So please, can anyone help me with one of the solutions above? Pick the easiest! Help will be greatly appreciated, not only from me.
Summary
-Windows Server 2003
-Apache 2.2 with OpenSSL
-Mercurial 1.8.2
-I can clone, but not push!
Thank you!
Maarten Baar(s)
It seems like you might have apache configured incorrectly for getting it to do what you want. Based on your question it sounds like you have a path (maybe the root of the server) pointing to the repository you want to serve.
Mercurial comes with a script for this exact purpose, in the latest version it is hgweb.cgi. There are reasonably good instructions for setting it up on the mercurial site. It should allow both cloning and pushing. You will need the push_ssl=false if you will not be configuring https and also an allow_push line which will let certain users, or all (*) push to the repository. But all that should be part of the setup docs.

CouchDB replication is not working properly behind a proxy

Note: Made some updates based on new information. Old ideas have been added as comments below.
Note: Made some updates (again) based on new information. Old ideas have been added as comments below (again).
We are running two instances of CouchDB on separate computers behind Apache reverse proxies. When attempting to replicate between the two instances:
curl -X POST http://user:pass#localhost/couchdb/_replicate -d '{ "source": "db1", "target": "http://user:pass#10.1.100.59/couchdb/db1" }' --header "Content-Type: application/json"
(we started using curl to debug the problem)
we receive an error similar to:
{"error":"case_clause","reason":"{error,\n {{bad_return_value,\n {invalid_json,\n <<\"<!DOCTYPE HTML PUBLIC \\\"-//IETF//DTD HTML 2.0//EN\\\">\\n<html><head>\\n<title>404 Not Found</title>\\n</head><body>\\n<h1>Not Found</h1>\\n<p>The requested URL /couchdb/db1/_local/01e935dcd2193b87af34c9b449ae2e20 was not found on this server.</p>\\n<hr>\\n<address>Apache/2.2.3 (Red Hat) Server at 10.1.100.59 Port 80</address>\\n</body></html>\\n\">>}},\n {child,undefined,\"01e935dcd2193b87af34c9b449ae2e20\",\n {gen_server,start_link,\n [couch_rep,\n [\"01e935dcd2193b87af34c9b449ae2e20\",\n {[{<<\"source\">>,<<\"db1\">>},\n {<<\"target\">>,\n <<\"http://user:pass#10.1.100.59/couchdb/db1\">>}]},\n {user_ctx,<<\"user\">>,\n [<<\"_admin\">>],\n <<\"{couch_httpd_auth, default_authentication_handler}\">>}],\n []]},\n temporary,1,worker,\n [couch_rep]}}}"}
So after further research it appears that apache returns this error without attempting to access CouchDB (according to the log files). To be clear when fed the following URL
/couchdb/db1/_local/01e935dcd2193b87af34c9b449ae2e20
Apache passes the request to CouchDB and returns CouchDB's 404 error. On the other hand when replication occurs the URL actually being passed is
/couchdb/db1/_local%2F01e935dcd2193b87af34c9b449ae2e20
which apache determines is a missing document and returns its own 404 error for without ever passing the request to CouchDB. This at least gives me some new leads but I could still use help if anyone has an answer offhand.
The source CouchDB (localhost) is telling you that the remote URL was invalid. Instead of a CouchDB response, the source is receiving the Apache httpd proxy's file-not-found response.
Unfortunately, you may have some reverse-proxy troubleshooting to do. My first guess is the Host header the source is sending to the target. Perhaps it's different from when you connect directly from a third location?
Finally, I think you probably know this, but the path
/couchdb/db1/_local%2F01e935dcd2193b87af34c9b449ae2e20
Is not a standard CouchDB path. By the time CouchDB sees a request, it should have the /couchdb stripped, so the query is for a document called _local%2f... in the database called db1.
Incidentally, it is very important not to let the proxy modify the paths before they hit couch. In particular, if you send %2f then CouchDB had better receive %2f and if you send / then CouchDB had better receive /.
From official documentation...
Note that HTTPS proxies are in theory supported but do not work in 1.0.1. This is because 1.0.1 ships with ibrowse version 1.5.5. The CouchDB version in trunk (from where 1.1 will be based) ships with ibrowse version 1.6.2. This later ibrowse contains fixes for HTTPS proxies.
Can you see which version of ibrowse is involved? Maybe update that ver?
Another thought I have is with regard to the SSL certs. If you don't have any, and I know you don't :), then technically you're doing SSL wrong. In java we know there are ways around this, but maybe try putting in proper certs since all SSL stuff basically involves certs.
And for my last contribution (today) I would say have you looked through this document which seems highly relevant?
http://wiki.apache.org/couchdb/Apache_As_a_Reverse_Proxy