Develop Reference

Protect vaadin 8 views with pre-authorize (spring security)

I'm currently developing a Vaadin 8 app with spring boot and as I've read on many posts, the correct way of securing a view is to annotate the class with PreAuthorize. I'm doing that to protect views like this:
#SpringView(name="arinteractions")
#PreAuthorize("hasAuthority('OWNER') or hasAuthority('ADMIN')")
public class ARInteractionsView extends SideMenuViewBase {
The first problem I encountered was that my roles didn't have the ROLE_ prefix so I added that.
Still, spring was allowing the user to enter any view just by typing its URL (which in vaadin is a hashbang like #!interactionview).
Adding this allows the user with access to enter the view, but also users without access. When a user without the roles tries to enter the views he they open. The logs show:
Found view ARStorageBanksView annotated with #PreAuthorize but no access decision manager. Granting access.
And also an exception is thrown:
org.springframework.security.access.AccessDeniedException
at org.springframework.security.access.vote.AffirmativeBased.decide(AffirmativeBased.java:84) ~[spring-security-core-5.0.4.RELEASE.jar:5.0.4.RELEASE]
I tried adding an access decision manager by adding a bean maker method in the security config, but I didn't found any documentation on how to implement this correctly.
Also, adding the access decision manager only made it worse. All views became blocked and the logs showed that the views 'didn't exist'.
What I did to solve was to use the old #Secured annotation. That for some reason is working flawlessly.
Spring security Roles, Authorities, are very confusing. Some of its objects are strings, some are plain objects, the auth scripts are hard to debug, the convetions aren't obvious that are required.
So the question is, what is the correct way of setting up security so that I can use the newer pre-authorize?

I think there is nothing wrong using #Secured, especially if it works. The Vaadin reference application (Bakery) has been implemented using that as well. See more at: https://vaadin.com/start/v8-full-stack-spring

In Spring MVC, does using 'redirect:process' or 'redirect:/process' differ regarding causing a lost session or session value?

I am experiencing strange behavior in my Spring MVC 3.2 application, and I noticed that this only happening when the redirect is done in an alternate way; so my questions are:
Is doing 'redirect:/process' any different from
'redirect:process' for redirecting to an internal controller ?
Does the added slash make any difference, such as affecting session handling ?
What are the reasons for a lost session (or lost session attributes) ?
There's a value I read through my application; even thou I do redirects in many cases, when I add a slash before the Controller URI, on production I am sometimes losing this value.
Any clue on how to troubleshoot the lost session value ?
Note: I am using methods httpRequest.getSession().setAttribute and httpSession.getAttribute for accessing the session.

with '/' you are declaring a path from root, which is your servlet context path. without '/', usually it's going to a path relative to your current sub path. for example, if you are at '/go/url', your are pointing to '/go/url/next', not '/next'.
I didn't check spring source code but that's how it works in web browser usually.
EDIT:
I'm sorry, in Spring MVC, you must always provide full path, not just relative path. So you should do "redirect:/full/path".

Just a note: / is a slash, backslash is \.
Except for external causes because of other errors, neither redirect:process not redirect:/process should change anything as long as the session is concerned.
But those 2 redirects are not supposed to do the same thing, unless you are on the root application page. Assuming that your application runs on HTTP port 80 on server.domain, with a servlet context of myapp, and you are processing a request to http://server.domain/myapp/local/part, redirect:process would ask browser to request http://server.domain/myapp/local/part/process, when redirect:/process would ask browser to request http://server.domain/myapp/process.
What happens next depends on your controller mappings.

You probably want to analyse, what is causing the lost session attributes. One approach would be to implement your own HttpSessionAttributeListener and log in public void attributeRemoved(HttpSessionBindingEvent event) implementation. Also keep spring log level to debug.

How does spring-ldap bypass OpenLDAP's "unique" overlay? And how do I stop it from doing this?

I have an OpenLDAP deployment with uniqueness constraints on certain attributes (created with the "unique" overlay), which I have tested using ldapadd and confirmed to be working properly. But when I add a conflicting entry using the "bind" method of org.springframework.ldap.core.LdapTemplate, the entry is saved without being validated.
Is this supposed to happen, or is there something buggy about one of my environments? And if it is supposed to happen, how do I get spring-ldap to stop sneaking past the uniqueness constraint?

This could possibly be due to a known issue with OpenLDAP, if spring isn't explicitly adding the RDN attribute when it adds the entry:
http://www.openldap.org/lists/openldap-bugs/201210/msg00065.html

Spring LDAP uses JNDI for communication with the LDAP Server. By default JNDI sends ManageDsaIT control. If set the OpenLDAP Server ignores the unique overlay.
You can disable this behaviour by setting the following environment variable:
java.naming.referral=throw
When using a spring boot service you can set:
spring.ldap.base-environment:
java.naming.referral: "throw"

jetty unknow domain 404 error page

I have two webapps on one jetty server. Each has own domain, defined in jetty-web.xml, for example example1.com and example2.com. This is working fine. Now, if someone will point some other domain name(let it be example3.com) to my server, and tryed to access it by this name - server will not found context configuration for this new domain and will send default responce with list of installed apps. And I need to change this functionality - i want just hide list of my webapps. In documentation thay suggest use some webapp, named root. It is ok, but than i get conflict of names and this default webapp is overriding my applications, if it was deployed last. So my question is - how do i can change this default 404 page for hidding webapp list.

You need to prevent Jetty from showing context related information.
Hint: you can even write own implementation of DefaultHandler and inject in in same way as inbuilt is injected, as far as jetty.xml is IoC-style config.

Lazy init doesn't work in Spring MVC 3

I'm facing a problem with Spring dependency injection. I have an application that once deployed checks if it's previously configured, if not then it launches configuration manager and asks the user for db host, port, admin login and pass etc.
Now I can't find a way to inject those configured values. I assume that I would have to use lazy init beans but when i add the annotation #Lazy, Spring is still trying to inject them at the runtime and I'm getting an error since the host and port are not yet configured.
What am I missing :/?

You need a lookup method, a feature accessible only through XML configuration. There is an almost ancient JIRA issue still open on this, still unresolved.
Please do check this comment on the mentioned issue, it describes a workaround that may be an option for you.