Make it easier to include custom stylesheets when using Spring Security

[sissbruecker]

Describe your motivation

In v25 we want to recommend using @StyleSheet as the default way of loading CSS in an application. However, when you enable Spring Security and then add a custom stylesheet, it's not going to be loaded:

@StyleSheet(Aura.STYLESHEET)  
@StyleSheet("styles.css")  
public class App implements AppShellConfigurator {}

To get the styles loaded I have to:

• Figure out the issue is related to Spring Security
• Figure out the magic incantation to permit loading my custom styles

Which sucks, because my current task is styling the application, not figuring out how Spring Security works. It's also confusing because the Aura styles are loading due to our custom Spring security rules for that.

This behavior is also a downgrade compared to the legacy theme folder, which just made things work out of the box.

Describe the solution you'd like

CSS included with @StyleSheet should always load, regardless of the security configuration.

[mcollovati]

I'm not completely sure about automatically adding permitAll security rules for stylesheets.
Two reasons come to my mind:

• let's say we add a rule for styles.css. But if the CSS then imports other stylesheets? Should we recursively parse to find all potential import statements?
• It can potentially open the door for security issues, for example, if an add-on adds the annotation with a path pointing to an HTTP endpoint instead of a CSS file.

[sissbruecker]

let's say we add a rule for styles.css. But if the CSS then imports other stylesheets? Should we recursively parse to find all potential import statements?

That would be one option. We could also change it so that in dev mode it loads the stylesheet from a servlet that inlines all sources, and in production just puts the inlined CSS in the resources.

It can potentially open the door for security issues, for example, if an add-on adds the annotation with a path pointing to an HTTP endpoint instead of a CSS file.

Definitely not an expert here, but how is that different to not using Spring Security?

In general, we don't have to figure out the technical solution now, and it's OK to take some time to think about the implications and possible solutions. For now this issue just states that the @StyleSheet experience is worse than the legacy theme folder experience, so maybe we should do something about that.

[mcollovati]

Probably I'm a bit rude here 😄 , but if you set up your application for security, you have to know what should be secured and what should be public.

Definitely not an expert here, but how is that different to not using Spring Security?

It is not different at all. If you are using a different security framework or your "home made security framework"™️ you are in charge of securing resources. Or maybe I did not correctly get the question?

For now this issue just states that the @Stylesheet experience is worse than the legacy theme folder experience, so maybe we should do something about that.

Got your point 👍

[knoobie]

Just my two cents:

• Vaadin should be secure by default
• Vaadin should automatically be able to load developer defined static resources

This falls perfectly onto my comment from yesterdays PR: those resources should be loaded from e.g. a namespace that is "owned" by Vaadin, e.g. /VAADIN/css

[mcollovati]

Vaadin should automatically be able to load developer defined static resources

I'm still missing something obviously 😄
To better understand, if you put an image in src/main/resources/images and reference it from a Image component, do you expect Vaadin to automatically handle security for that path?
My feeling is that if my application uses static resources, I'm in charge of making them accessible publicly when required.
Or I can put them into a well-known folder and instruct Spring Security with helpers like StaticResourceRequest.atCommonLocations() (@knoobie IIRC you suggested this on another issue or forum post)

Vaadin should be secure by default

Not enabling paths automatically just because an annotation looks like a "secure by default" practice 😄 (just kidding)

[knoobie]

You are right :) I wasn't clear enough, files that are managed by Vaadin (css/js) should be handled automatically. Images or other static resources should be managed like suggested previously (I'm still in favor of this). Especially those files that are handled by your build pipeline, renamed, merged or other magic is applied (compressed.. and so on) must be handled by Vaadin automatically. Otherwise people end in a similar situation as the favicon problem with it's 20+ generated paths

I'm personally still unsure about the following:

• should all Stylesheets be public, or should there a way for a developer to define it's availability @Stylesheet(..., access=PUBLIC, ROUTE_ACCESS...)
• in the same regard: should all @Stylesheets be merged (the other issue from today).. even Stylesheets from private (e.g. /admin) parts of the application or should there be a way for developer to define the "merge target" for stylesheets? @Stylesheet(..., mergeTarget=/public/css/index.css)

TLDR: The whole Stylesheet / Removal of Theming needs a good concept :x