Hello all,
We are using a security package on our backend that has a servlet filter that checks request headers for two important parameters. I need to be able to send those headers along with POST requests to the server. How would I go about doing this?
Just to understand your question: do you want to call the API or provide the API?
Hi Simon,
I apologize for being unclear. I don’t have a lot of Vaadin experience, so I don’t quite know how to answer. I believe I just want to call the API.
Basically, I have a lot of calls to /?v-r=uidl&v-uiId=1 (with various querystring parameters) in an existing Vaadin app that are failing because of receiving a 403. I basically need all XHR calls from the frontend to include the headers the servlet filter is expecting.
That’s no such built-in functionality. You would have to polyfill the browser API that sends the requests or intercept them with a service worker.
Or convince your security team that those headers don’t make a difference with Vaadin’s security model.
As Leif said, it doesn’t really match Vaadin’s security profile… we don’t know what your filter expects so I can just provide a semi-matching suggestion…
If it’s some kind of static information, use a reverse proxy in front of your application to apply the “missing” headers to make your filter happy.
Sounds like there is a generic custom HTTP security/auth mechanism and proxy in between client and server, which has nothing to do with the built-on Vaadin application security mechanisms?
I remember overriding Vaadin communication on client-side to inject extra stuff to every HTTP request sent by the browser. But that was for Vaadin 8 and I used GWT and I guess you are on newer Vaadin version? Then that solution might not apply here.
Maybe you could do similar overrides using XMLHttpRequest.prototype directly?
Hi all, I should clarify what is going on. We have pac4j on our backend, which manages calls to a Keycloak server in order to tie our applications into a single sign on. I need to be able to provide a token to pac4j in order for it to handle our XHR requests. (Non-XHR requests are no problem because the browser redirects work.)
I understand that Vaadin provides an SSO Kit that ties directly into Keycloak but that requires the premium plan, which we don’t subscribe to.
From what I gather from the responses here, it wouldn’t really be possible to integrate a Vaadin app with an authorization server like Keycloak without upgrading to get the SSO Kit. Is that a fair statement?
SSO kit is not mandatory. This works flawlessly without it. Sounds more like a problem about understanding how pac4j, keycloak and vaadin could work together. You might wanna take a look into the Vaadin Spring Security Integration - where exactly this is also done by leveraging the oauth2 login
I suppose this token is generated on the server side by pac4j and sent to the client in some way to be added to every subsequent request. If so, couldn’t you use a httpOnly cookie instead of an HTTP header?
Otherwise, could you please elaborate a bit more on how your solution is supposed to work?
I understand how pac4j works with Keycloak. But you are right that I do not understand how to integrate pac4j and Vaadin. That’s what I am trying to figure out. I looked at the Vaadin Spring Security Integration document but I don’t see anything that’s not Spring specific. Is there something in particular in there that I’m supposed to take away from that document?
I prefer to look at source code instead of docs…
I’m not familiar with pac4j, but google got me to this example Pac4J Integration with Embedded Tomcat 10 using Generic OAuth via Keycloak | BuildingTents which made me think: Vaadin should not create any problem and all requests should get the session cookie and you are good to go… so it’s really hard for us without a full example you are struggling with
Just to have it asked: could you please point to the PAC4J Docs, what
feature we are talking about? And just in case, that it is an
CSRF-Token: Vaadin has it’s own CSRF prevention.
Thanks to everyone for their help on this. I will be experimenting with some changes and will see what works.