- Q. Is IG compatible with Oracle® Java Development Kit (JDK) 11?
- Q. Can I run multiple IG instances on the same server?
- Q. Can I run IG in the same web application container instance as AM?
- Q. Do AM and IG need to be running on the same web application container version?
- Q. Can I install IG and AM on the same VM instance?
- Q. Can I terminate SSL at the load balancer?
- Q. Why does IG have to be installed as the root application?
- Q. How do I configure IG to not enforce URI authorization for certain file types?
- Q. Does IG support URI rewriting?
- Q. How do I change the timezone used for timestamps in the log files?
- Run each IG instance in its own web application container instance since IG must be run as the root context web application (for example, ROOT.war in Apache Tomcat™).
- Use different ports for each web application container instance.
- Use different base configuration directories for each instance. By default, configuration files are stored in the $HOME/.openig directory, so you would want to change this, for example, $HOME/.openig1, $HOME/.openig2 etc. See Changing the Default Location of the Configuration Folders for further information.
- Rename the cookie used for JwtSession if instances run under the same hostname but you do not want to share the stateless session across instances. You do not need to rename this cookie if you want the stateless session to be shared across all IG instances running in a cluster. In this scenario, you need to ensure that the keys/certificates are also the same. See JwtSession for further information.
See IG (All versions) redirects to HTTP when a reverse proxy or load balancer is doing SSL/TLS offloading for further information about this configuration.
A. If the intention is to use IG as a reverse proxy for all requests, there shouldn't really be a scenario where you would want to deploy it as anything other than root. If it is not in the root context, you would be restricting applications that can be proxied to since they need to be in the same context.
There is also code within IG that implicitly assumes it is deployed in the root context.
A. You can use route conditions to control which requests are handled by IG as detailed in Setting Route Conditions or configure the web application container to serve the files instead.
See How do I configure IG (All versions) to access unprotected static content and resources? for further information.
A. Yes, as of IG 7, URI path rewriting is supported. A UriPathRewriteFilter is available to rewrite the path of a request URL. See UriPathRewriteFilter for further information.
In previous versions, you can use a ScriptableFilter as detailed in ScriptableFilter if you need to rewrite URLs. Unfortunately, we do not provide an example ScriptableFilter for this purpose as there are many different use cases and it can be error prone working with the regular expressions needed to rewrite links in HTML pages.
Resolved RFE: OPENIG-1664 (Provide support for basic URI path rewriting).
See Default Logging Behavior for the full reference logback.xml file.
You can change UTC to specify the required timezone. The format required is dictated by the TimeZone.getTimeZone(String) method specification. This means you can use an abbreviation such as "PST", a full name such as "America/Los_Angeles" or a custom ID such as "GMT-8:00". If the timezone is unknown or misspelled, the GMT timezone is assumed. IG might need restarting depending on the Logback configuration.
Audit logs use timestamps in UTC format, which is not currently configurable. An RFE exists for this: OPENIG-4467 (Allow timezone change in audit logging).