I've setup proxied authentication for RStudio Server.
RStudio Server is redirecting to a middleware implemented using Express JS
The middleware creates a request to the authentication server and then parses the response from it.
Then the middleware adds the X-RStudio-Username header to the response, which is a re-direction to the RStudio. However, the header is added to the response from the middleware, and then the browser doesn't keep it when it redirects to RStudio Server
Since the browser request doesn't have the required header, RStudio requests the authentication again creating an infinite loop
How should I approach this case?
What would be the best way to add the required header for RStudio Server?
The browser won't add this header for you. You need to add it in the layer that proxies traffic through to RStudio Server. If you don't have such a layer already, you will need to add it using e.g. Nginx. This layer could authenticate the request using whatever mechanism your auth provider supports and add the X-RStudio-Username header (which we recommend renaming for security reasons).
Since you're using RStudio Server Pro, our support team would be happy to help you with this:
support#rstudio.com
You'll also be glad to know that we're working on SAML support for an upcoming release of RStudio Server Pro!
Related
I have a keycloak client sample-application. It has valid-redirect-uri https://sample-application.mycompany, a frontend service. This frontend calls backend service, sending JWT token in http header. Backend service checks allowed-origins in this JWT token. https://sample-application.mycompany is there, so everything works fine in production.
"allowed-origins": [
"https://sample-application.mycompany"
]
Now we are doing some e2e tests, and we are calling this backend, but from a different place - http://jenkins.mycompany. We have a proper JWT token, but backend service fails on allowed-origins validation, because http://jenkins.mycompany is not there.
My options:
add additional valid-redirect-uri http://jenkins.mycompany to my client - I don't want to do that, adding testing stuff to production clients seems bad
make copy of a client sample-application-testing, with additional valid-redirect-uri, use it for tests, delete afterwards
tried using server's private-key to generate my own JWT with extra entry in allowed-origins, but it failed later, because server validates this token
tried some magic with setting different Origin headers, but it seems impossible, browser protection I guess
Is there any other possibility?
Edit - the validation I'm talking about, checks if Origin header is in allowed-origins list. To be clear: this is not something I invented myself. This validation comes from keycloak-spring-boot-starter, here is the relevant fragment: https://github.com/keycloak/keycloak/blob/17117820cc14f87f5990ddce80ef38a0e2e7f314/adapters/oidc/adapter-core/src/main/java/org/keycloak/adapters/AuthenticatedActionsHandler.java#L126
Keycloak allows one to add multiple multiple Valid Redirect URIs as well as multiple Web Origins. One of these should allow you to add the URL for your test server and have it appear in the Allowed Origins in the JWT.
More commonly, test environments will have their own copy of production servers so as not to interfere with production operations. This is pretty standard. For a CI/CD setup, it makes more sense to use some kind of a stub or mock validator (something that can be spun up locally) to avoid setting up a server entirely
Below is a screenshot of the settings in the Client configuration in Keycloak 19
I currently have an API running on Nodejs Express where you can get or upload all types of files (images, videos...) as well as simple json responses.
I would like to connect Sveltekit to this API but it is secured with a SSO so I need to provide an access token for each request.
I already get the access token from the SSO (oidc) on sveltekit.
Solution 1:
a service workers intercept requests to the API and add the access token.
Problems: I don't want to build every time but as the documentation says: service workers only work in the production build, not in development
Solution 2:
send requests to the svletekit backend and then pipe them to the API with the access token
Problems: Works only for basic requests but not for stream, it seems that it is supported recently (https://github.com/sveltejs/kit/issues/5344) but there is no documentation or example and this solution requires more resources (requests should be from the browser to the api)
Solution 3:
Hooks externalFetch
This function allows you to modify (or replace) a fetch request for an external resource that happens inside a load function that runs on the server (or during pre-rendering).
Problems: It doesn't work for requests like the src of an image
Any idea ?
edit: Solution, with the new version of sveltekit node-fetch has been replaced by Undici and the streams are functional, so it is possible to pipe requests from the backend.
For the dev it work well but it's not the best solution for production so you can use both depending on the environnement.
I am using Angular 5 to send post request to send SMS through Bulksms : http://bulksms.com/
When making the request from Angular (client), I am facing this issue :
Origin http://TTTT:4200 is not allowed by Access-Control-Allow-Origin.
How can I correct this issue in BulkSMS ?
Regards,
Your browser's same-origin policy is restricting your Javascript code from accessing a third party (i.e. api.bulksms.com in this case) in the way in which you hoped to do it - and CORS (Cross-Origin Resource Sharing), which is a mechanism to relax those restrictions, is not relaxed enough to allow these requests (from you as an untrusted third party) either.
Wikipedia Same-origin policy : "Under the [same-origin] policy, a web browser permits scripts contained in a first web page to access data in a second web page, but only if both web pages have the same origin. An origin is defined as a combination of URI scheme, host name, and port number. This policy prevents a malicious script on one page from obtaining access to sensitive data on another web page". The Wikipedia page contains some good examples of the sorts of malicious Javascript code uses that the same-origin policy tries to limit.
It is important to note that these restrictions are only enforced by browsers: HTTP client code that is not running under a browser typically doesn't care about any of this.
For development purposes, there are some tools that can make your life easier - for example, you could use live-server to run a simple HTTP server which serves up your static files, while also using its --proxy option to route requests to api.bulksms.com and solve your same-origin policy problem in the process.
For production, a typical solution is to route your AJAX requests, which are destined for the third party service, via your own server (the one serving up your Javascript files to your browser), or a reverse proxy (which would front both your own and the third party service). If there is a server side to your application, you can make the HTTP requests to api.bulksms.com from there, using an HTTP client, and then have your Javascript code talk to your own server, to indirectly make the requests to bulksms.com. This also gives you the opportunity to add authentication headers on your server side, without your Javascript code ever having to know them (e.g. if you have one bulksms.com account, and many users able to use that account via your Angular app, but who should not know your credentials). Similarly, you could impose limits on what your Angular users can do in this way (e.g. to limit the number of SMSs they could each send per day).
I am using Anypoint Studio 6.1 and Mule 3.8.1 and have a mule RESTful application that I want to stop CORS requests from being accepted by the application.
The application has been setup to do this but what is the best way to prove this is working?
From what I have read so far, the examples build their own application and I would just like to do something like send a request configured as a CORS request in Postman. How can I do this?
Thanks
I want to stop CORS requests from being accepted by the application.
I would just like to do something like send a request configured as a CORS request in Postman
You mean you want to block cross-origin requests just from Web applications running in browsers?
Given that browsers are the only tools that enforce CORS restrictions, and they only do it for requests from code running in actual Web apps—not for requests from extension such as Postman that aren’t bound by the same-origin policy that Web apps are—then you’re not going to be able to use CORS to block requests from Postman or from code not running from a Web app in a browser.
The application has been setup to do this but what is the best way to prove this is working?
Confirm the service isn’t sending an Access-Control-Allow-Origin response header—which it never would be unless either it were explicitly configured to do that or it’s built using some server-side programming environment/framework that adds Access-Control-Allow-Origin by default.
But since browsers are the only tools that are ever actually going to block cross-origin requests due to lack of Access-Control-Allow-Origin, you really can only test the blocking in a Web app.
Otherwise you can at least test outside the browser to see what response headers are returned by the server the requests are sent to. The main thing to do in that case is to be sure the request send an Origin header (some servers only send Access-Control-Allow-Origin if a request includes an Origin header—because browsers are the only tools that automatically send Origin.
So, using curl for example, you’d want to do this:
curl -H "Origin: https://example.com" https://service.to.test/
I see most examples using it with form-based authentication (i.e. we load the mod_auth_form.so and other session modules). Is it possible to use this session timeout along with basic authentication (i.e. we load mod_auth_basic.so ) ?
Also, I know that the mod_session was introduced only after apache2.3, so this would definitely not be supported in apache2.2 I am fine even if it works just for apache 2.4.
It's not implemented in any other auth modules, but it's also unnecessary. Most other auth modules use HTTP basic auth, where the credentials are seamlessly transmitted on every subsequent request to the same host+context root.
But mod_auth_form needs to do a one-time capture/prompt/validate that cannot be propagated on every request. Hence the need to put them in a session store.