I’m working on an Eclipse Scout application that needs two different access levels. The public part should be available at the root URL without requiring login, while the protected area should be under /app path.
Here’s what I’m trying to achieve:
Public frontend: Available at mysite.com with pages like Home, About, and a contact form. Protected backend: Accessible at mysite.com/app after authentication.
I have a few specific questions:
What’s the proper way to create and register a custom servlet that handles the root path “/”? Should I extend any specific Scout servlet class?
How can I modify the authentication URL to point to /app instead of the default?
For the public frontend, I want to display user information if someone is already logged in. What’s the best approach to check and retrieve the current user session?
Any guidance on implementing this dual-access structure would be really helpful.
for the servlet part, you’d typically extend HttpServlet rather than scout-specific ones since you’re handling public content. register it in web.xml with url-pattern “/” and use a filter to bypass scout’s auth for public paths. the tricky bit is session sharing - you might need to manually check scout’s session store to see if user is logged in.
I implemented something similar last year and found success with a custom ResourceServlet approach. Instead of extending HttpServlet directly, I created a servlet that extends AbstractHttpResourceServlet from Scout’s framework, which gives you better integration with Scout’s resource handling while still allowing public access. The key is configuring your servlet mapping in the ServletContainerInitializer with a higher priority than Scout’s default mappings. For the authentication redirection, override the getLoginUrl method in your custom AuthFilter to return “/app/login” instead of the default path. Regarding session checking for logged-in users on public pages, I used Scout’s IServerSession.current() within a try-catch block since it returns null for unauthenticated requests rather than throwing exceptions. This approach maintains clean separation between public and protected areas while leveraging Scout’s existing infrastructure.
interesting setup you’re going for! are you planning to use the same scout session management for both areas or keep them seprate? i’m curious how you’ll handle the ui framework - will the public part still use scout’s ui components or something more lightweight like plain html/jsp?