<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Topics tagged with proxy]]></title><description><![CDATA[A list of topics that have been tagged with proxy]]></description><link>https://fusionauth.io/community/forum/tags/proxy</link><generator>RSS for Node</generator><lastBuildDate>Sun, 14 Jun 2026 09:56:56 GMT</lastBuildDate><atom:link href="https://fusionauth.io/community/forum/tags/proxy.rss" rel="self" type="application/rss+xml"/><pubDate>Invalid Date</pubDate><ttl>60</ttl><item><title><![CDATA[Receiving 502 errors when using Cloudflare in front of FusionAuth]]></title><description><![CDATA[<p dir="auto">This is due to non-ASCII characters in headers causing an issue in the FusionAuth parsing code. Cloudflare sends headers with non-ASCII characters (such as cf-region: São Paulo) which triggers this issue.</p>
<p dir="auto">This is <a href="https://github.com/FusionAuth/java-http/issues/25" rel="nofollow ugc">a java-http bug that was fixed in 2024</a>, and released in <a href="https://fusionauth.io/docs/release-notes/#version-1-51-2" rel="nofollow ugc">FusionAuth version 1.51.2</a>.</p>
<p dir="auto">So, two options:</p>

upgrade to a version of FusionAuth 1.51.2 or newer. This is the recommended approach, but may require some work.
as an interim workaround, you can disable the "Add visitor location headers" option from your CloudFlare console. This should not have any negative impact, since we do not inspect those headers.

]]></description><link>https://fusionauth.io/community/forum/topic/2932/receiving-502-errors-when-using-cloudflare-in-front-of-fusionauth</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/2932/receiving-502-errors-when-using-cloudflare-in-front-of-fusionauth</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[Apache2 reverse proxy setup exposing directory listings and serving unintended files]]></title><description><![CDATA[<p dir="auto"><a class="mention plugin-mentions-user plugin-mentions-a" href="https://fusionauth.io/community/forum/uid/20">@dan</a> The configuration files and logs are inaccessible, assuming you're talking about the ones residing up a directory from /fusionauth-app/.</p>
<p dir="auto">Thank you for stating the risks of the leakage. The only thing that raised flags here was the default fusionauth.properties file in the template directory had the default database user and password, but those should be, and were, changed when installing.</p>
<p dir="auto">I will fork and submit a PR later tonight or this week.</p>
<p dir="auto">Thanks again.</p>
]]></description><link>https://fusionauth.io/community/forum/topic/2405/apache2-reverse-proxy-setup-exposing-directory-listings-and-serving-unintended-files</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/2405/apache2-reverse-proxy-setup-exposing-directory-listings-and-serving-unintended-files</guid><dc:creator><![CDATA[ctrenner]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[Security and PKCE]]></title><description><![CDATA[<p dir="auto">Hiya,</p>
<p dir="auto">PKCE is great and should be used if supported. This helps prevent authorization code replay attacks, as recommended here: <a href="https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#page-6" rel="nofollow ugc">https://tools.ietf.org/html/draft-ietf-oauth-security-topics-16#page-6</a></p>
<p dir="auto">Using a proxy and storing the access token on server side rather than javascript solves a different set of security concerns. Because access tokens are typically bearer tokens and are not sender constrained, anyone who gets them has access to whatever they grant access to.</p>
<p dir="auto">This means that if your javascript has access to the token, so does any other javascript running on your page. If you are comfortable with that (you've audited all the javascript in all the libraries, and their dependencies to ensure that there's no security issues) then storing the access token may be ok.</p>
<p dir="auto">Since that level of comfort with javascript libraries is not typical (do you know what is going on in the dependencies of your dependencies? many folks don't), we recommend one of two approaches:</p>

store the access token server side, and use the session to tie the client to the access token (what our blog posts typically do)
store the access token in a secure, httponly cookie, so that it is not accessible to javascript, but is sent to any APIs. That's more fully fleshed out here: <a href="https://fusionauth.io/learn/expert-advice/authentication/spa/oauth-authorization-code-grant-jwts-refresh-tokens-cookies/" rel="nofollow ugc">https://fusionauth.io/learn/expert-advice/authentication/spa/oauth-authorization-code-grant-jwts-refresh-tokens-cookies/</a>

<p dir="auto">Of course, you alone know your security posture and what you're comfortable with, but that's what we recommend.</p>
]]></description><link>https://fusionauth.io/community/forum/topic/504/security-and-pkce</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/504/security-and-pkce</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[IIS as a reverse proxy?]]></title><description><![CDATA[<p dir="auto">We don't have any IIS guides for a proxy, but this guide looks like it would work: <a href="https://docs.microsoft.com/en-us/iis/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing" rel="nofollow ugc">https://docs.microsoft.com/en-us/iis/extensions/url-rewrite-module/reverse-proxy-with-url-rewrite-v2-and-application-request-routing</a></p>
<p dir="auto">The key is that version 1.19.x of FusionAuth is completely stateless so the proxy can round-robin and no session pinning is required. If you are using a version of FusionAuth before 1.19, you'll need to pin your session to ensure that you can log into the administrative interface.</p>
]]></description><link>https://fusionauth.io/community/forum/topic/422/iis-as-a-reverse-proxy</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/422/iis-as-a-reverse-proxy</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item><item><title><![CDATA[Can I use a proxy with FusionAuth?]]></title><description><![CDATA[<p dir="auto">There's no supported way. Here's the <a href="https://fusionauth.io/docs/v1/tech/common-errors" rel="nofollow ugc">official docs</a>:</p>
<blockquote>
<p dir="auto">FusionAuth is able to handle all HTTP traffic and any network handling between the browser and FusionAuth should be as simple as possible.</p>
</blockquote>
<p dir="auto">However, this solution was found by a community member (for the <a href="https://fusionauth.io/docs/v1/tech/installation-guide/docker" rel="nofollow ugc">docker install</a>). Configure the environment variable:</p>
<p dir="auto">FUSIONAUTH_ADDITIONAL_JAVA_ARGS: -Dhttp.proxyHost=some.proxy -Dhttp.proxyPort=8210 -Dhttp.nonProxyHosts="localhost|127.0.0.1|10.*.*.*|172.*.*.*"</p>
<p dir="auto">before you start FA and it should work.</p>
]]></description><link>https://fusionauth.io/community/forum/topic/76/can-i-use-a-proxy-with-fusionauth</link><guid isPermaLink="true">https://fusionauth.io/community/forum/topic/76/can-i-use-a-proxy-with-fusionauth</guid><dc:creator><![CDATA[dan]]></dc:creator><pubDate>Invalid Date</pubDate></item></channel></rss>