I've got pretty much what is in this code, at least the important parts for this question.
When I try to access some not-existing page, I don't get 404, but firstly, I get authentication dialog and I have to write credentials, to see 404. Thats not what I expect from 404 and routing. How can I overcome this issue?
Thanks a lot and Merry Xmas to all of you!
your top level lets the public paths have the first chance to supply a response, and If they don't match (or otherwise choose not to respond) then the request falls through to the part that requires authentication:
(defroutes app-routes
public-routes
(wrap-basic-authentication protected-routes authenticated?)
(route/not-found "404 Not Found"))
If, after authenticating, the route is not found then it returns a 404. Because there is no way to tell before authenticating if the private routes will claim the request all requests are falling into the wrap-basic-authentication handler. This causes the request for authentication to happen before deciding if the path is valid. It makes a lot of sense for wrap-basic-authentication not to allow an unauthenticated user to map the site by trial and error before authenticating, so it requires authentication before it will even tell you if a path exists.
In the private paths handler all the paths start with "admin" Which if it where accessible outside the protected section of the site would be a great way to know if a request like "/foo/bar/" is not private and does not exist and thus should get merit a 404 response. If you hoist the word "admin" to the top level handler and drop the wrap-basic-authentication into the private routes that should give you useful error messages without allowing unauthenticated people to map the private area of the site.
something like:
(defroutes app-routes
public-routes
(context "/admin/"
(wrap-basic-authentication protected-routes authenticated?))
(route/not-found "404 Not Found"))
Then remove the word "admin" from the start of each private path.
Related
Ok, feeling dumb. I've been following https://auth0.com/blog/securing-kubernetes-clusters-with-istio-and-auth0/ to secure a flask app through an ingressgateway.
Basically, my AuthorizationPolicy is being seen (whitelisted routes are working, other routes are denied (enforced denied, matched policy none)) but anything that requires a jwt (key: request.auth.claims[...] or even source: requestPrincipals: ["*"]) fails.
Adding Envoy debug information, I don't see any Authorization header, which may be part of the problem; flask of course stores the access token as part of its session cookie (as in the linked article). And it seems as you'd need something like that for Istio to see it in the request; I tried setting an access_token cookie directly and using an EnvoyFilter to try and break it out into an Authorization header but that didn't seem to work either (I probably got the envoy filter wrong; new to them but I was trying an envoy.filters.http.jwt_authn filter with from_cookies; nice idea but I can't even tell if it's being called).
I'm baffled at this point. How do I store the user's jwt after the OIDC shuffle in such a way that the browser sends it back in a way that Istio is happy with? By default Istio really seems to want the Authorization header, but I'm not clear how to get it (or if that's desired). Seems like an obvious pattern but searching comes up surprisingly short, which makes me feel like I'm missing something Really Obvious.
Edit:
After investigating this further, it seems cookies are sent correctly on most API requests. However something happens in the specific request that checks if the user is logged in and it always returns null. When refreshing the browser a successful preflight request is sent and nothing else, even though there is a session and a valid session cookie.
Original question:
I have a NextJS frontend authenticating against a Keystone backend.
When running on localhost, I can log in and then refresh the browser without getting logged out, i.e. the browser reads the cookie correctly.
When the application is deployed on an external server, I can still log in, but when refreshing the browser it seems no cookie is found and it is as if I'm logged out. However if I then go to the Keystone admin UI, I am still logged in.
In the browser settings, I can see that for localhost there is a "keystonejs-session" cookie being created. This is not the case for the external server.
Here are the session settings from the Keystone config file.
The value of process.env.DOMAIN on the external server would be for example example.com when Keystone is deployed to admin.example.com. I have also tried .example.com, with a leading dot, with the same result. (I believe the leading dot is ignored in newer specifications.)
const sessionConfig = {
maxAge: 60 * 60 * 24 * 30,
secret: process.env.COOKIE_SECRET,
sameSite: 'lax',
secure: true,
domain: process.env.DOMAIN,
path: "/",
};
const session = statelessSessions(sessionConfig);
(The session object is then passed to the config function from #keystone-6/core.)
Current workaround:
I'm currently using a workaround which involves routing all API requests to '/api/graphql' and rewriting that request to the real URL using Next's own rewrites. Someone recommended this might work and it does, sort of. When refreshing the browser window the application is still in a logged-out state, but after a second or two the session is validated.
To use this workaround, add the following rewrite directive to next.config.js
rewrites: () => [
{
source: '/api/graphql',
destination:
process.env.NODE_ENV === 'development'
? `http://localhost:3000/api/graphql`
: process.env.NEXT_PUBLIC_BACKEND_ENDPOINT,
},
],
Then make sure you use this URL for queries. In my case that's the URL I feed to createUploadLink().
This workaround still means constant error messages in the logs since relative URLs are not supposed to work. I would love to see a proper solution!
It's hard to know what's happening for sure without knowing more about your setup. Inspecting the requests and responses your browser is making may help figure this out. Look in the "network" tab in your browser dev tools. When you make make the request to sign in, you should see the cookie being set in the headers of the response.
Some educated guesses:
Are you accessing your external server over HTTPS?
They Keystone docs for the session API mention that, when setting secure to true...
[...] the cookie is only sent to the server when a request is made with the https: scheme (except on localhost)
So, if you're running your deployed env over plain HTTP, the cookie is never set, creating the behaviour you're describing. Somewhat confusingly, in development the flag is ignored, allowing it to work.
A similar thing can happen if you're deploying behind a proxy, like nginx:
In this scenario, a lot of people choose to have the proxy terminate the TLS connection, so requests are forwarded to the backend over HTTP (but on a private network, so still relatively secure). In that case, you need to do two things:
Ensure the proxy is configured to forward the X-Forwarded-Proto header, which informs the backend which protocol was used originally request
Tell express to trust what the proxy is saying by configuring the trust proxy setting
I did a write up of this proxy issue a while back. It's for Keystone 5 (so some of the details are off) but, if you're using a reverse proxy, most of it's still relevant.
Update
From Simons comment, the above guesses missed the mark 😠but I'll leave them here in case they help others.
Since posting about this issue a month ago I was actually able to work around it by routing API requests via a relative path like '/api/graphql' and then forwarding that request to the real API on a separate subdomain. For some mysterious reason it works this way.
This is starting to sound like a CORS or issue
If you want to serve your front end from a different origin (domain) than the API, the API needs to return a specific header to allow this. Read up on CORS and the Access-Control-Allow-Origin header. You can configure this setting the cors option in the Keystone server config which Keystone uses to configure the cors package.
Alternatively, the solution of proxying API requests via the Next app should also work. It's not obvious to me why your proxying "workaround" is experiencing problems.
(Note, I'm using Reagent, Secretary, and Compojure (among others))
I want to create a route /sectest/:id, and if I point my browser to that route, I get the following error:
Resource interpreted as Stylesheet but transferred with MIME type text/html: "http://localhost:3449/sectest/css/site.css".
asdf:1
Refused to execute script from 'http://localhost:3449/sectest/js/app.js' because its MIME type ('text/html') is not executable, and strict MIME type checking is enabled.
But if I click on a link in the browser that navigates to that route, it works fine...
Here's the pertinent code:
Client Side:
(secretary/defroute "/sectest/:id" [id]
(do
(js/console.log (str "Hi " id))
(session/put! :current-page #'my-page)))
Server Side:
(defroutes routes
(GET "*" [] loading-page) ;this anticipates client-side routing only
(GET "/cards" [] cards-page)
(resources "/")
(not-found "Not Found"))
(def app (wrap-middleware #'routes))
So the following link takes me to my-page, and the console prints "Hi asdf" just fine:
[:div [:a {:href "/sectest/asdf"} "SECTEST"]]
But if I type in http://localhost:3449/sectest/asdf, I get an error, and I can't seem to trace it. I suspect it might have something to do with the code trying to find resources located at /sectest, (which it shouldn't), but I can't confirm this or figure out how to work with it... I am new to clojure, so forgive if I'm massively ignorant on some point, any thoughts?
Take a look at your server side routing, effectively you only have one route:
(GET "*" [] loading-page)
As it handles everything all following routes will never trigger. Order matters:
(defroutes routes
(GET "/cards" [] cards-page)
(resources "/")
(GET "*" [] loading-page) ;this anticipates client-side routing only
)
The above should do the trick, I removed the 404 route, as this should be handled by the frontend routing.
The reason it currently works when clicking on a page link in your SPA is that it will get handled by secretary. If you enter the url manually you are doing a page reload and the request is handled by compojure initially.
Edit:
After taking a closer look, relative links to your css/js files in your html template are most likely the culprit here:
/sectest/js/app.js
The compojure resources route won't match and the default catch all route loading-page is served as css/js file to your browser. Hence the error.
For my dev env I also had to correct the :asset-path of my boot cljs task as the source mapping files suffered from the problem. Should be similiar with lein-figwheel.
In Compojure one can define default 404 behavior, e.g.,
(defroutes app-routes
;; ...
(route/not-found "These aren't the droids you're looking for."))
As we've been increasing the number and complexity of REST endpoints, we've been looking into switching to Swagger / compojure-api. Swagger seems higher level and quite different from basic Compojure. What's the correct idiom for customizing 404 behavior using this library?
There is no definition in the Swagger Spec for the "missed everything else" default handler of Compojure. Swagger is about documenting existing apis, not the non-existing. Just discussed about this at #swagger on freenode.
Still, you can describe the default routes manually with compojure-api, created a sample here: https://gist.github.com/ikitommi/cdf19eeaf4918efb051a.
Note: Swagger spec doesn't actually understand the ANY -http method, but does seem to work with the 1.2 Swagger UI - will not work with codegens. To be standard compliant, you should add manually handlers for all http methods (https://github.com/swagger-api/swagger-spec/blob/e42dd2011340a12efbb531f593c0f99c831c4582/schemas/v1.2/operationObject.json#L10) to the end of your route definitions.
hope this helps.
I'm having trouble with my Clojure server middlewares. My app has the following requirements:
Some routes should be accessible with no problems. Others require basic authentication, so I'd like to have an authentication function that sits in front of all the handler functions and makes sure the request is verified. I've been using the ring-basic-authentication handler for this, especially the instructions on how to separate your public and private routes.
However, I'd also like the params sent in the Authorization: header to be available in the route controller. For this I've been using Compojure's site function in compojure.handler, which puts variables in the :params dictionary of the request (see for example Missing form parameters in Compojure POST request)
However I can't seem to get both 401 authorization and the parameters to work at the same time. If I try this:
; this is a stripped down sample case:
(defn authenticated?
"authenticate the request"
[service-name token]
(:valid (model/valid-service-and-token service-name token)))
(defroutes token-routes
(POST "/api/:service-name/phone" request (add-phone request)))
(defroutes public-routes
controller/routes
; match anything in the static dir at resources/public
(route/resources "/"))
(defroutes authviasms-handler
public-routes
(auth/wrap-basic-authentication
controller/token-routes authenticated?))
;handler is compojure.handler
(def application (handler/site authviasms-handler))
(defn start [port]
(ring/run-jetty (var application) {:port (or port 8000) :join? false}))
the authorization variables are accessible in the authenticated? function, but not in the routes.
Obviously, this isn't a very general example, but I feel like I'm really spinning my wheels and just making changes at random to the middleware order and hoping things work. I'd appreciate some help both for my specific example, and learning more about how to wrap middlewares to make things execute correctly.
Thanks,
Kevin
AFAIK, ring.middleware.basic-authentication doesn't read anything from the :params in request and ring.core.request/site doesn't put anything authentication-related there either.
But in any ring handler, you can still access the headers. Something like:
(GET "/hello"
{params :params headers :headers}
(str "your authentication is " (headers "authentication")
" and you provided " params))
Similarly, you can use that to write your own middleware to put authentication-related stuff in params, if you really want to.