We are currently using Thymeleaf to parse templates. We want to offer this feature to our users so that users can provide custom templates. However, Thymeleaf is very powerful and is able to call methods and access static resources.
Is there any way to disable both invoking Java methods (Or whitelist some vital calls), as well as disabling Thymeleaf from being able to access static fields and methods?
We only have to allow users to use basic IF statements, loops and accessing object fields.
In short - afraid not.
We are currently using Thymeleaf to parse templates. We want to offer this feature to our users so that users can provide custom templates. However, Thymeleaf is very powerful and is able to call methods and access static resources.
It is, and it's designed to do so with no (secure) way that I'm aware of for disabling this functionality. Even if you could disable what you want with some kind of preprocessor hack, relying on it being watertight seems incredibly risky to me - I really wouldn't advise it. (Even if users don't access anything untoward for instance, they could still execute random code repeatedly to bog the server down and make the page load slowly.)
Instead, I'd look to the more "normal" route of exposing the functionality that users are expected to see via an endpoint that they can call via AJAX. They can then build their forms in plain old HTML / JS, making additional calls to any other resources that they need along the way.
If you're worried about extra AJAX calls, you could also statically inject a JSON object that contains everything the user may need in the header of the page - they can then display the content of that wherever they want.
Related
I'm using Vaadin Flow to develop a web app with Java. I would like to know the best way to handle login and authorization. I've been giving this a thought and I'm not sure the best way to do this.
I have a login view and a main app view with a content holder for nested layouts.
How do I check that the user is logged in and what permissions does it have to see or not see some part of the app? I've read about BeforeEnterEvent and ReRouting but it's still not very clear.
Do I have to use BeforeEnterEvent for each class I have? Do I have to create a class with user parameters like a boolean to check if it's logged in and a string for the kind of authorization it has? And where do I create or save this instance?
Is there a simple way to do this? Like to start with an empty layout and to start that with the login screen, then the login screen decides to swap for the main app view? And how do I prevent the user to type the address of the main view in the bar and access parts it shouldn't access like: /app/adminsettings
I'm sure this is way simpler but I think I have my head overloaded by now, thanks anyone in advance!
As always, there are no silver bullets. The "best way" always depends on
the requirements and your options range from Basic Auth to some external
OIDC provider.
There are already some tutorials out there with the most prominent from
Vaadin itself about Spring
Security
(which in a previous iteration had a flaw that compromised security,
which of course shows again, that security is no product but a process
and demands constant validation).
So I want to strategize here a bit more about the problems you are
facing and some things to consider:
Be aware, that when you use a security library, that has or allows for
an web path centric approach, that you should only use it for the
root and to open up paths to resources etc. The history API may only
look like you are fetching URLs from a server or web sockets may be
used under the hood and suddenly those rules no longer apply.
If you are using the annotation based way to add routes, you end up
with all the routes, that are there, for your UI per user. So it's
good to familiarize yourself with how to register routes
dynamically.
E.g. only add the routes the user is allowed on login; this usually
also has implications for the UI (e.g. menu entries).
There usually is some initial "declarative" security part (can the
user even enter this view; this usually means some simple role check).
A good place to check for this is a BeforeEnterListener added to the
UI; it will be called before any navigation to any view. See
navigation
livecyle
The next entry point(s) to guard are the BeforeEnterEvent you can
listen on in the view itself and/or maybe it implements
HasUrlParameter. If you take params from the "request" or the path,
the usually mean further checks (e.g. is the acting user allowed to
edit the blog entry with the id 42). See routing and URL
parameters
and also navigation
livecyle.
Deeper into the application you end up with something more imperative,
that libraries often make appear declarative, because they generate
some code for you from some annotation (e.g. some AOP that generates
the code around your #SecurityCheck('${u.owner}==${currentUser}')
void save(User u) method, that checks for the role and whether the
User u belongs to the acting user).
Be very certain, that your IoC system/library/... sees those
annotation and generates the code accordingly. Only #Route e.g.
will get the full DI treatment with Vaadin+Spring - for the rest it's
your job that the DI-framework can do it's job (a NPE from a missed
#Autowired is spotted very quickly, but a security check not being
called, is not). The obvious way around this, is to be imperative and
write the code yourself instead of relying on it to be there.
If you have an anonymous system and then some login, make sure to send
users over to a fresh session (and therefor UI); not only does it
prevent a session fixation attack, but it also allows you put all your
route-setup and UI derivations according to security in one place at
the beginning of the UI creation. If you have state you want to carry
over, make it part of the URL, that your successful login process
sends them back to or park in the browsers local storage.
I used a couple of Java template engine (Mustache, Freemarker) and I always struggle on how to deal with the same problem.
Assume you have a template with a piece of code like:
<a href="/{{article.name}}/{{article.color}}/home.html">
where article is an object passed from a controller to the template engine, for instance.
Then, I always see the same problems. I have to hardcode the url in several pages, if I change it then I have to look at it manually everywhere. E.g., if I want to change the URI like this:
<a href="article/{{article.name}}/{{article.color}}">
Then I have to change it everywhere.
Yeah, maybe I can define each url in something that is enabled by specific template engines (e.g. includes), but I'm wondering if there is a best practice.
One possible solution I was thinking about is to create the urls on the server side (e.g. in the controller) and sending them to the view.
Which are the best approaches from the point of view of re-usability, correctness and flexibility?
You said it: The best (most flexible and maintenable) practice is to produce the URLs in the controller and send them to the view: That is called HATEOAS.
for a java web application, normally we need to do validation at front end using javascript and then on the backend using java, some java validation tools like hibernate validator can be used on the backend side, while on client side there're jquery form vaildation,
but the thing is, is there a simpler way to combine the two? such as, when using springmvc with hiberate validator, the front end valiation will be there automatically?
thx
Don't forget, there are two very different forms of validation.
First, validation to ensure that the user makes sensible entries. Consider the usual password/confirm-password system. The only significance of the confirm-password field is keep the user from accidentally inconveniencing himself.
Similarly, things like checking valid email addresses, required fields, and so forth -- they're just there to make sure the user is entering what he really means.
Second, there is validate to ensure that only legal changes are made to the system. One user cannot change data belonging to another user, employees cannot give themselves raises, and so forth.
Validations of the first kind need only be done in Javascript. The user can defeat them, if he wishes, but he hurts no one but himself.
Validations of the second kind must be done on the back-end. Usually, but not always, there isn't any need to err out gracefully. If the user has weaseled past the UI, or reverse-engineered the AJAX, you don't have to be polite. Just return a 500 and log the intrusion.
There are a few overlaps. For example, if user is creating a (supposedly) unique user-name, that uniqueness check can fail at the very last second, after passing all the Javascript checks, because someone else took a previously unused name.
But that's the exception, not the rule. Most back-end validation is just very thin security or security-like checks, very different from what's done on the front.
I'm working on some user related tasks for a website. For cases when the person is registering or editing a user, they fill out a form and the request is handled in a servlet. At the moment, the servlet is taking all the request parameters and building a User object from them, like this:
User toRegister = new User(request.getParameter("name"),
request.getParameter("lastName"));
There's more parameters but you get the point.
So this sort of code is being reused in a bunch of different servlets (registering, admin adding user, user updating self, admin updating others etc) and it's kinda ugly, so I wanted to clean it up. The two alternatives I could think of were a constructor that takes the request object or a static method in the User class to create and return a new User based on the request.
It's not much of a question since I know they would both work but I couldn't find any sort of best practices for this situation. Should I keep to handling the requests individually in the servlets in case the forms change or should I implement one of the above methods?
DON'T add a c'tor that takes a Request as an argument. You only couple your User class to the Servlet API this way.
Instead use a Web Framework as #skaffman suggests. There are many of these, and it will make your life easier.
EDIT: If you refuse to learn a new framework you can at least use BeanUtils of some similar framework to do the data binding only. I do recommend the Web Framework option though.
Instead of coding all the business logic in the servlet, why dont you use basic MVC framework. Using a framework will make your coding and testing a lot easier.
Is there a Java web framework that allows
the user to create custom fields, like in Mantis bugtracker?
http://www.mantisbt.org/wiki/doku.php/mantisbt:features
Here's what I actually want to do:
Allow the user to create a template / form that has several custom fields
(textboxes, checkboxes, comboboxes, etc.)
Once a template has been created (of which several others can also be made),
he can use the template, and save data inputted into the fields.
I am planning to use Spring and Hibernate along with this,
though other suggestions are also appreciated.
Like comments suggests, it is not a framework duty to provide you that kind of fields, it is your duty, as an application developper, and depending upon your requirements, to provide such a feature.