I am using one Wildfly based application. I have deployed application inside docker and accessing it through AWS load-balancer. Also, I have enabled "proxy-address-forwarding=true" in standalone.xml with ip based filter for path as -
<expression-filter name="ipAccess" expression="path-prefix('/auth/admin') -> ip-access-control(default-allow=false, acl={'127.0.0.1/32 allow', '172.17.0.0/16 allow', '192.168.0.0/16 allow' })"/>
But whenever I am trying to access application, I am getting 403 Access Denied. Filtering works fine for me if I removed "proxy-address-forwading=true" from standalone.xml
Related
I am trying to run websphere behind ingress.
I have successfully configured the ingress for it and I am able to access the console.
The ip on which I am able to access the console is
https://mydomain/ibm/console/logon.jsp
Note: I have a domain , for which I created a A record.
When I login into the console ,
I am redirected to
https://mydomain:9043/ibm/console/
This page does not exist.
If I explicitly run the URL https://dns/ibm/console/login.do?action=secure. My application works fine.
Can someone tell me where is the configuration needed so that it is not redirected to dns:port?
I have created all the config following the URL:
Problem configuring websphere application server behind ingress
The request is http://hostname/ibm/console/logon.jsp and it returns http://hostname:9080/ibm/console/logon.jsp
This is causing confusion and thus we are facing an issue.
The port which our was app uses is controlled by two properties:
trusthostheaderport = true
com.ibm.ws.webcontainer.extractHostHeaderPort = true
These can be created in the WAS Admin console under:
Servers > Server Types > WebSphere application servers > [server_name] > Web Container Settings > Web container > Additional Properties > Custom Properties
Setting both of these properties with a value of "true" should force WAS to use the front-end port (from the Host header) instead of the Webcontainer port.
Note: You need to restart the service after the change ( restart in case of docker containers)
Please find the documentation here.
I'm trying to setup my own instance of nextcloud on my server but I'm running into a problem as I want nextcloud to be available under https://example.com/cloud/.
Next cloud is running in a CoreOS virtual machine called let's say myvm.
So this is the way I setup my CaddyFile:
example.com {
gzip
proxy /cloud myvm:8080 {
transparent
without /cloud
}
}
I have other proxies that work fine for other services or VMs that are written similarily.
With this, and publishing port 8080 in my docker-compose file, I manage to connect to the nextcloud instance. But every time I go to example.com/cloud/ it will redirect me to example.com/apps/files/ instead of example.com/cloud/apps/files/.
If I enter this last url manually, I can access to nextcloud, but also the page doesn't load properly because all the contents cannot be loaded because they are not prompted with the prefix cloud/.
Is there a way to explain nextcloud about this prefix through the configuration of docker-compose file? (It's the only configuration I created, it works with just that and no extra work, I use one similar to the one available here (the apache one).)
Or maybe I can improve the CaddyFile config? (By the way, if I don't use the without option, it will just not work at all and return 404 when I go to the url).
Previously I was running ColdFusion 10 configured with Apache on my localhost. I am using a different machine now and I am now using ColdFusion 11's built in web server. I have imported settings from an archived ".car" file. My app uses ColdFusion Rest services which were working on my previous machine. I have setup the rest service on this new machine and I am using the same service name but with a different absolute path to directory.
for example:
previous directory: - D:/foo/bar/api/v2
current directory: - C:/foo/bar/baz/api/v2
The rest service is registered and gets refreshed successfully in the ColdFusion Administrator. But when I try to access the API path on localhost, I get this 500 error :
This page isn’t working
localhost is currently unable to handle this request.
HTTP ERROR 500
Application v2 could not be found. The specific sequence of files included or processed is: ''''
I get the following error message when I try to open up my application from the web (using 'appname' as my application name, the root name of my application - the error displays my app's actual name):
com.ibm.ws.webcontainer.internal.WebContainer handleRequest SRVE0255E: A WebGroup/Virtual Host to handle /appname has not been defined.
As far as I can tell, my application was installed correctly and is running on our Websphere server (WAS 8.5).
I'm at a loss for what to pursue in order to resolve this issue - what possible issue could my application be having?
Map your web module to /appname in the administration console, or use whatever context-root is specified for the web module.
I've created Web Application running on Java Liberty Runtime on Bluemix. Login is done by using SSO service with SAML enterprise provider. After login user redirected to my app and on every JAX-RS request I get user's credentials by following code:
Subject s = WSSubject.getCallerSubject();
Object credential = s.getPrivateCredentials().iterator().next();
String loginToken = credential.toString();
Everything works fine, but if the user has been idle for more then 10 minutes and then perform any ajax request WSSubject.getCallerSubject() returns null, and I required to refresh application.
I've tried to increase timeout by adding following attribute to web.xml:
<session-config>
<session-timeout>60</session-timeout>
</session-config>
But it didn't help. So I'm looking how can I increase timeout or possible I can retrieve user credentials in a different way?
You need to add the optional element <authCache> to the server.xml file to change the default values for the authentication cache.
As you mentioned in your question, the default value is 10 minutes. To change it to 60 minutes you need to include the following in the server.xml file:
<authCache initialSize="50" maxSize="25000" timeout="60m"/>
The documentation here provides more details and also explains initialSize and maxSize options, I left the default value for these two above and just updated timeout.
If you are deploying your application using the default method of pushing the war file, you will need to use a different approach to deploy the application with a custom server.xml file. Please check the documentation here for options on pushing Liberty profile applications (more specific check sections Server Directory and Packaged Server).
In this case, you may also want to check the server.xml file that is currently deployed and modify that version to add the <authCache> element.
You can get a copy of the file by running the following command:
$ cf files <your_app_name> app/wlp/usr/servers/defaultServer/server.xml