I configure my Alfresco instance to be in a sub-URI (www.example.com/prefix/alfresco , www.example.com/prefix/alfresco/share) and all looks to be fine except that I can't log in Shared. The Catalina.out log this error:
ERROR [alfresco.web.site] [http-apr-28080-exec-10]
javax.servlet.ServletException: Possible CSRF attack noted when
asserting referer header
'http://www.example.com/prefix/alfresco/share/page/'. Request: POST
/prefix/alfresco/share/page/dologin, FAILED TEST: Assert referer POST
/prefix/alfresco/share/page/dologin :: referer:
'http://www.example.com/prefix/alfresco/share/page/' vs server &
context: http://10.140.8.144/ (string) or (regexp)
Then the browser show me this page (www.example.com/prefix/alfresco/share/dologin):
Something's wrong with this page...
We may have hit an error or something might have been removed or
deleted, so check that the URL is correct.
Alternatively you might not have permission to view the page (it could
be on a private site) or there could have been an internal error. Try
checking with your Alfresco administrator.
If you're trying to get to your home page and it's no longer available
you should change it by clicking your name on the Alfresco toolbar.
I tried to deactivate the CSRF filter in share-config-custom.xml, but then I can't log and I don't have any message in the log, the login page show:
Your authentication details have not been recognized or Alfresco may
not be available at this time.
My apache conf:
ProxyPass /prefix/alfresco
http://10.140.8.144:28080/prefix/alfresco ProxyPassReverse
/prefix/alfresco http://10.140.8.144:28080/prefix/alfresco
ProxyPass /prefix/alfresco/share
http://10.140.8.144:28080/prefix/share ProxyPassReverse
/prefix/alfresco/share http://10.140.8.144:28080/prefix/share
I could log before configure Alfresco for work in the reverse proxy.
There is no need to deactivate the CSRF filter. If you changed the context path as described in the documentation you need to make sure that the tomcat connector "knows" the outside context (hostname, port, context).
Either
set proxyName and proxyPort
set RemoteIpValve in tomcat server.xml and set required proxy header
variables in apache (x-forwarded-for, x-forwarded-by,
x-forwarded-proto)
use proxy_ajp instead of proxy_http and define a ajp connector in
tomcat
Related
I've successfully configured Apache to listen over SSL/443 and proxy Tomcat listening on HTTP/8080. I have also set up basic authentication in Apache.
Once the user connects to my Tomcat servlet, will the HttpServletRequest.getRemoteUser() be populated or null. If null, how might I get the remote user?
The simplest solution may be to use mod_proxy_ajp, which in addition to proxying requests also transfers a variety of metadata to Tomcat, including authentication information such as REMOTE_USER.
These docs for Alfresco discuss this configuration, which includes changes on both the Tomcat side (so that it knows to trust the forwarded authentication) and the Apache side.
If you're using a generic http proxy like mod_proxy, you would need to arrange for Apache to add the value of REMOTE_USER to the request (possibly as an X- header), and then arrange for your Tomcat application to recognize and trust that header (and you would obviously need to arrange for your front-end proxy to strip that header from any incoming requests).
I don't know how you would do this on the tomcat side, but this post seems to have some suggestions.
I needed to add
<Location />
Order allow,deny
Allow from all
RequestHeader unset Authorization
</Location>
to the wrapping location, the RequestHeader being the specialty that fixed it.
I found this (again) via http://codeblow.com/questions/remove-fundamental-authentication-header-with-apache-mod-proxy/ - don't know where I originally found it last year, it was a last measure for some security issue.
Tomcat in our application is considered back-and side and additionaly we have apache that fronting tomcat server as a reverse proxy and redirect requests to appropriate tomcat instance.
Now we need to set up HTTPS connection between apache proxy and tomcat for specific urls(Login, etc..). Tomcat documentation says that it's possible to achieve this with additional <Connector> within server.xml config.
In order to set up https over login page existing configuration with AJP protocol was replaced with the following:
ProxyPass /app/login/ https://127.0.0.1:6666/app/login/
All other urls specified like below:
ProxyPass /app/anyotherurl/ ajp://127.0.0.1:5555/app/anyotherurl/
With configuration below we expect that secure data (login/password) for login page will be encrypted and all other page will remain unchanged.
After the login apache should use normal ajp protocol because there is no sensetive information any more to protect. But it's not what actually happen in our case because for some reason apache is redirecting us to host specified in ProxyPass, namely to localhost.
This could happen due to the fact that our application while executing login logic on tomcat has two consecutive redirects.
We've tried to set ProxyPreserveHost on within virtual host to fix situation mentioned above, but we are not sure whether it is secure option and this one won't break another pages as well as we are not sure how it will work if tomcat will be located on other machine.
It would be good to know any other solution how such stuff can be applied internally for specific pages.
We're running Sonatype's Nexus to store all of our builds, cache our dependencies, etc. etc. However, I'd like to move away from the default install's port 8081 URL and instead host it over SSL via an Apache proxy. I've setup Apache's mod_proxy to proxy to it such that https://myserver.com/nexus brings up Nexus. I used the following configuration directives inside of my virtual host config:
# Configure mod_proxy to be used for proxying URLs on this site to other URLs/ports on this server.
ProxyRequests Off
ProxyVia Off
ProxyPreserveHost On
<Proxy *>
AddDefaultCharset off
Order deny,allow
Allow from all
</Proxy>
# Proxy the Sonatype Nexus OSS web application running at http://localhost:8081/nexus
<Location /nexus>
ProxyPass http://localhost:8081/nexus
ProxyPassReverse http://localhost:8081/nexus
</Location>
This seems to match the instructions at Running Nexus Behind a Proxy. However, I was unable to clear the "Base URL" setting in Nexus: it wouldn't let me leave it blank.
And everything mostly works: I can access Nexus at the HTTPS URL, log in, and perform most GUI functions.
However, when logging in I get the following warning message:
WARNING: Base URL setting of http://myserver.com/nexus does not match your actual URL! If you're running Apache mod_proxy, here's more information on configuring Nexus with it.
And not everything in the GUI actually works. So far I've noticed the following:
System Feeds: Gives the following error:
Problem accessing /nexus/service/local/feeds. Reason:
The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request
Nexus returned an error: ERROR 406: The resource identified by the request is only capable of generating response entities which have content characteristics not acceptable according to the accept headers sent in the request
Deleting Hosted Repositories: I went through and deleted several empty & unneeded repositories. However, after confirming the deletions, only the first was removed. I had to login to the 8081 site to delete any of the others.
Per the documentation, it looks like a better solution may be to add a RequestHeader to the Apache configuration:
RequestHeader set X-Forwarded-Proto "https"
I tried the accepted answer, which appears to work, but once I added the RequestHeader, I was able to uncheck Force URL and the warning was cleared. I have not tested the other behavior the OP is describing, though.
You just need to adjust the baseUrl setting in the Administration->Server configuration screen. Set the url you are using and click the Force Base Url option.
I configured Apache Jackrabbit 2.6.3 to use WebDAV in an anonymous mode (empty credentials are mapped to anonymous:anonymous).
If I click on a direct link to some file (e.g. JPG or DOC) HTTP 403 error is thrown by GlassFish server. If I press F5, 403 is still there.
BUT if I simply press Enter in address bar in my browser on the same URL, everything is OK, and resource is accessible.
I think that only difference is a referrer in the HTTP header.
I searched for any information about a similar problem, but I couldn't find anything.
Does anybody have some idea how to force WebDAV (or Jackrabbit) to serve files in the anonymous mode despite the referrer or any other reason?
I found a solution.
In web.xml file in section WebDAV the following part must be uncommented:
<init-param>
<param-name>csrf-protection</param-name>
<param-value>disabled</param-value>
</init-param>
With disabled as param-value.
As description says:
Defines the behaviour of the referrer based CSRF protection
1) If omitted or left empty the (default) behaviour is to allow only requests with
an empty referrer header or a referrer host equal to the server host
2) May also contain a comma separated list of additional allowed referrer hosts
3) If set to 'disabled' no referrer checking will be performed at all
Im trying to create a webchat using Jabber. I have installed Openfire and i can login to the admin panel at :9090 so the server is running.
Now when using strophe.js basic example, coming with strophe.js i get this error:
5XMLHttpRequest cannot load http://jabber.xxx.dk:7070/http-bind/. Origin http://jabber.xxx.dk is not allowed by Access-Control-Allow-Origin.
How can i allow the domain?
Thanks to #SamGoody for pointing this out. As of version 3.8.0, OpenFire now supports1 CORS[2], which is needed for your use case. To enable it, go to the OpenFire admin console, Server, Server Settings, HTTP Binding tab. Ensure that "Provides support for CORS (Cross-Origin Resource Sharing)" is Enabled, with a domain list of * (these are the defaults).
If it doesn't work even after enabling CORS in Openfire and changing the domain policy to accept all, then check your URL for Openfire. You may need to add '/' at the end (e.g. 'http://dimain:7070/http-bind/').
Without the slash it didn't work for me.
Another option is to setup your apache server to proxy port 7070 so you're not dealing with cross-domain issues per se. The code for that looks something like this inside of your httpd.conf file:
ProxyRequests Off
ProxyPass /http-bind http://127.0.0.1:7070/http-bind/
ProxyPassReverse /http-bind http://127.0.0.1:7070/http-bind/
If you log in to the admin panel, go to the Server Settings tab, then to HTTP Bindings, check both options (HTTP Binding and Script Syntax) are set to Enabled
I had faced same issue and come to know that port was not open for access.
Though it browser says it is CORS Access-Control-Allow-Origin issue.
This is sometimes open port issue. Please make sure http bind port is open and can be accessible over tcp on system your are testing.