Hi,
What’s the best way of adding REST endpoints to an existing Hilla Application which uses the authentication mechanism generated by Hilla?
I’m running Hilla 2.0.5
Hilla uses standard Spring security. So you don’t have to do anything
Simply use the annotations
Also noting, that it is possible to have annotations also in end point methods, so that you can restrict e.g. some methods to be admin only, while the default for the rest of the methods is logged in users hilla-demo/src/main/java/com/example/application/data/endpoint/CrmEndpoint.java at master · TatuLund/hilla-demo · GitHub
So I can add, for example, the GetMapping and PostMapping annotations to endpoint methods to expose them as REST endpoints?
See the example I shared. That is an endpoint, that uses Hilla’s own @Endpoint annotation. This should you primary option to create endpoints in Hilla app. These endpoints are those which will be scanned by TypeScript code generator of Hilla, which will create facades for your client code, so that you can easily consume these endpoints. That is the whole point of Hilla.
Yes you can use them like in any Spring app. But if you use it in the frontend you should go with Endpoint annotation
I understand that. What I am asking about it is endpoints for pure REST services that don’t use any sort of GUI. Am I able to create a REST controller that can access the authentication tables provided by Hilla?
This is a question re non frontend usage. I guess the question should be is how can I alter the security configuration such that REST services can authenticate without the login gui appearing but leave the rest of the Hilla application functioning as is
How would you like to authorize the REST services? Basic Auth? JWT?
JWT preferable
You can mix login methods in the SecurityConfiguration
And allow both
Where will you get the JWT from? Do you have Keycloak?
You can mix login methods in the SecurityConfiguration
This is the bit I’m unsure about doing.
Where will you get the JWT from?
In the first instance I was planning on adding a login endpoint to generate a token, then look at a more robust way of handling this further down the line