When a JSP site uses HTTPS, the login flow depends on more than the login form itself. SSL/TLS, redirects, cookie settings, and the way Apache or Tomcat is configured all affect whether a user stays authenticated after submitting credentials. In a UK-facing hosting setup, this often shows up as one of a few common problems: the browser keeps returning to the login page, sessions are lost after a redirect, the application mixes HTTP and HTTPS URLs, or the form submits correctly but the next page does not recognise the user.
For JSP and servlet applications hosted through a control panel such as Plesk, these issues are usually caused by a combination of application logic, reverse proxy behaviour, Tomcat connector settings, and HTTPS enforcement at the web server level. If you use a private JVM or Apache Tomcat instance through a managed hosting platform such as My App Server, it is important to understand how SSL termination and redirects interact with session cookies and application URLs.
How SSL changes the login flow on JSP sites
SSL, more accurately TLS, protects traffic between the browser and the web server. For login pages, this matters because credentials and session cookies should always be sent over HTTPS. However, when an application was originally written for HTTP or has hardcoded URLs, enabling SSL can change request routing and session handling.
In a JSP application, the login flow usually works like this:
- The user opens the login page over HTTP or HTTPS.
- The browser submits the form to a server endpoint, often a servlet or JSP controller.
- The application creates a session and issues a session cookie.
- The user is redirected to a protected page.
If SSL is introduced into this flow, the browser may treat requests differently depending on:
- Whether the site force-redirects from HTTP to HTTPS.
- Whether cookies are marked as Secure.
- Whether the application generates absolute URLs with the correct scheme.
- Whether Tomcat sees the original request as HTTP while the browser is using HTTPS.
- Whether the redirect chain preserves the session correctly.
Any mismatch can make the session appear to disappear even though the login itself succeeded.
Common login problems caused by redirects
HTTP to HTTPS redirect loops
A redirect loop happens when the browser is sent between HTTP and HTTPS repeatedly. This is often caused by two layers both trying to enforce the redirect, for example Apache redirect rules and application logic inside JSP or a security filter.
Typical signs include:
- The login page keeps refreshing.
- The browser reports too many redirects.
- The site appears to work until the user signs in.
In hosted JSP environments, this can happen if Tomcat believes the request is HTTP while Apache has already terminated SSL and forwarded the request internally. The application then redirects the user back to HTTPS or to a canonical host name, creating a loop.
Session loss after redirect
After login, many JSP applications redirect the user to a protected area. If the session cookie is not available on the redirected URL, the application may treat the user as anonymous and send them back to the login page.
This is usually linked to one of these causes:
- The cookie is scoped to a different domain or subdomain.
- The cookie is marked Secure and the first request is still HTTP.
- The redirect changes the host name, such as from www to non-www.
- The application uses a different context path than the login form expects.
- Tomcat is not aware that the original request was HTTPS.
Mixed protocol URLs inside JSP pages
If a JSP page contains absolute links starting with http://, the browser may downgrade part of the session to an insecure request. This can trigger browser warnings, blocked cookies, or a session split between secure and insecure requests.
Even if the login form itself uses HTTPS, one insecure image, script, stylesheet, or redirect target can interfere with the experience and sometimes affect authentication flows indirectly.
Why Tomcat and Apache need to agree on the original scheme
In many managed hosting setups, Apache handles the public HTTPS connection and forwards requests to Tomcat or a private JVM. When SSL is terminated before the request reaches Tomcat, the application server must be told that the original request was secure.
If this information is missing, JSP code may behave as if the request is plain HTTP. That affects:
- Secure cookie handling.
- Redirect generation.
- URL rewriting.
- Security checks based on request scheme.
For example, a login filter might contain logic that redirects a user to HTTPS when the request scheme is not secure. If Apache already handled HTTPS and Tomcat still sees HTTP, the filter may redirect unnecessarily. This is one of the most common reasons for login problems on JSP sites behind a proxy.
In a Plesk-based hosting environment with My App Server, the practical fix is usually to make sure the application server connector receives the correct forwarded headers and that the deployed app trusts them appropriately. The exact method depends on the Tomcat version and connector configuration, but the principle is always the same: the application must know the real external protocol, host, and port.
What to check first when login fails after enabling SSL
If a JSP login flow broke after HTTPS was added or a redirect rule changed, check the following in order.
1. Confirm the redirect target
Open the login page and watch the browser address bar. Make sure every step goes to the expected HTTPS URL and that the host name stays consistent.
- Use one host name only: either www or non-www.
- Avoid switching between different domains during login.
- Make sure the final post-login page uses the same protocol and host as the login form.
2. Check cookie attributes
Inspect the session cookie in the browser developer tools. Review:
- Secure flag: should usually be enabled for HTTPS login flows.
- Domain: should match the host name the user visits.
- Path: should cover the application context path.
- SameSite: must be compatible with the way the login flow works.
If the cookie is set for a different subdomain or path, the browser may not send it after the redirect.
3. Look for hardcoded HTTP links
Review JSP files, tag libraries, JavaScript, and form actions. Replace hardcoded absolute HTTP URLs with relative paths or HTTPS URLs. Pay special attention to:
- Form action attributes.
- Login success redirects.
- Links inside templates and includes.
- JavaScript calls that submit or redirect the page.
4. Verify Tomcat sees HTTPS correctly
If your hosting platform uses Apache in front of Tomcat, the application may need proxy-aware settings. If Tomcat does not understand the forwarded protocol, it may generate insecure redirects or reject cookie/session assumptions.
In practical terms, you should verify that the deployment matches the platform’s SSL offloading model. On managed hosting with a private JVM, this is often handled through the service configuration, but custom settings or uploaded application servers may need manual adjustment.
5. Review server-side authentication logic
Some JSP applications include custom login filters or servlet code that checks the request scheme before authenticating. If that logic assumes HTTP or does not handle forwarded HTTPS headers, it can cause false redirects or session resets.
Check for:
- Code that calls
request.getScheme()without proxy awareness. - Custom filters that redirect to a fixed URL.
- Security rules that compare the current host against an expected host.
Recommended configuration approach for hosted JSP applications
For a JSP application hosted in a control panel environment, the most stable approach is to keep HTTPS handling consistent at the edge and keep the application aware of the secure request context.
Use a single canonical URL
Choose one public URL for the site and login flow. For example, if the application should use https://example.co.uk, make sure both the login page and the protected area use that same canonical host.
This reduces:
- cookie mismatch issues.
- SEO duplication problems.
- redirect chains that break login state.
Redirect HTTP to HTTPS once, at the web server layer
Ideally, the HTTP-to-HTTPS redirect should happen in one place only. In managed hosting, that is usually the web server or the hosting control panel rule set, not inside the application code.
Keeping redirect logic out of JSP pages makes the login flow easier to troubleshoot and reduces the chance of loops.
Ensure cookies are aligned with HTTPS
Session cookies should be set so that they are sent reliably on the secure site. If the application is intended to operate only over HTTPS, the session cookie should generally be Secure and should not rely on HTTP access.
This is especially important for login forms, password resets, and remember-me functionality.
Make Tomcat proxy-aware
Where the hosting setup uses Apache in front of Tomcat, make sure the Tomcat service is configured to respect the original request scheme and host. In My App Server deployments, this is part of the practical value of having a private JVM and service control: you can align the connector behaviour with the application’s public HTTPS endpoint without changing the whole hosting account.
If you install a ready-made Java/Tomcat version through the control panel, verify after deployment that the app server starts correctly and that login pages open with the expected secure URLs.
Practical troubleshooting steps in Plesk and My App Server
If you are managing the site through Plesk and My App Server, use this workflow to isolate the issue.
- Open the site in a private browser window to avoid old cookies.
- Test the login page on HTTPS only.
- Check whether the login form action uses the correct protocol and host.
- Inspect the session cookie after submitting the form.
- Check the redirect response chain in the browser developer tools.
- Review Apache and application logs for repeated redirects or 401/403 responses.
- Verify that the Tomcat service is running with the intended Java version and app server configuration.
If the site works over HTTP but fails over HTTPS, the issue is usually either:
- a redirect rule that changes the URL in the wrong order, or
- a session cookie or proxy header mismatch.
If the site fails on both HTTP and HTTPS, the problem is more likely in the application authentication logic itself rather than SSL.
Examples of common failure patterns
Example 1: login succeeds, then the user is sent back to the form
This usually means the authentication succeeded, but the session did not persist across the redirect. Check whether the session cookie is being returned to the post-login page and whether the host name changed during the redirect.
Example 2: the browser reports too many redirects
This is often caused by HTTPS enforcement in both Apache and the application. Remove one redirect layer or make the application trust the forwarded HTTPS request.
Example 3: login works in one browser but not another
Different browsers handle SameSite, Secure, and third-party cookie rules differently. A browser that blocks weaker cookie settings may expose a configuration issue that other browsers tolerate.
Example 4: absolute URLs point to HTTP after login
This indicates that the application is generating URLs from an insecure scheme. Review JSP templates, controller redirects, and any code using the request object to build links.
Best practices for JSP login flows over HTTPS
- Use HTTPS for the entire login flow, not only the form submission.
- Keep one canonical host name and one canonical protocol.
- Avoid hardcoded
http://URLs in JSP files and scripts. - Let the web server handle HTTP to HTTPS redirection once.
- Make Tomcat aware of the original secure request when SSL is terminated upstream.
- Check session cookie scope after deployment or SSL changes.
- Test login after each configuration change, not only after the final release.
How SSL and redirects affect SEO and user trust
Although this article focuses on login behaviour, the same configuration choices affect search visibility and user trust. A secure, consistent HTTPS setup reduces duplicate URLs, prevents mixed content, and helps avoid browser warnings on public-facing pages.
For UK-facing sites, users expect a secure sign-in experience without unexpected protocol changes. Even if the application is a small or medium JSP-based system hosted on a private JVM, the public login flow should still be clean, predictable, and secure.
FAQ
Why does my JSP login stop working after I enabled HTTPS?
Most often, the app is still generating HTTP URLs, the session cookie is not being returned on the secure redirect, or Tomcat does not know that the request arrived through HTTPS at the Apache layer.
Should I redirect users to HTTPS inside JSP code?
Usually no. It is better to handle the HTTP-to-HTTPS redirect at the web server or hosting control panel level. Keeping this logic out of the application reduces redirect loops and makes troubleshooting easier.
Why does the session disappear after login?
The session cookie may be scoped to the wrong host or path, or the redirect may move the user to a different URL where the cookie is not sent. Check the cookie settings and the redirect destination.
Can mixed HTTP and HTTPS content affect login?
Yes. Mixed content can cause browser warnings, blocked resources, or unexpected behaviour in scripts that support the login page. It is best to keep all login-related resources on HTTPS.
What should I check in Tomcat first?
Check whether the application server is aware of the original secure request, especially when Apache or another front-end server terminates SSL. Also confirm that the deployed Java version and connector settings match the hosting platform’s expected setup.
Does this apply to private JVM hosting as well?
Yes. Even with a private JVM and control over the Tomcat instance, the same principles apply: correct proxy awareness, stable redirects, and session cookies that match the public HTTPS URL.
Conclusion
SSL does not usually break JSP login flows by itself. Problems appear when HTTPS changes the request path, redirect behaviour, or cookie handling in a way that the application was not built to expect. In a hosted Tomcat environment, especially where Apache and a private JVM work together through a control panel, the key is to keep the public URL, redirect rules, and application server configuration aligned.
If a login flow fails after SSL changes, start with the canonical URL, cookie scope, redirect chain, and proxy awareness in Tomcat. These checks resolve most HTTPS-related login issues on JSP sites without needing major application changes.