Fork me on GitHub

Where is :content-security-policy expected?


At which level in the resource map?



                        {:post ...}

        :access-control {:scheme "Basic", ...}
        :logger         (fn [ctx] (logging/info "Received request for ..."))}


The phonebook example in the Yada repository demonstrates the use of the "Basic" access-control scheme.


Note however that the phonebook example uses a more complete structure with a realm name as well as a vector of authentication schemes: {:realm "your realm" :authentication-schemes [{:scheme "Basic"}]}. Unless you want to support multiple authentication schemes you may simply specify a map with the :scheme and :verify key value pairs. It at least seems to work for me.


This is the article on authentication (basic, form-based/cookie, jwt) that I've had in draft for a while and will be the next to be published


The reason it requires the access token to access it is because it's still not quite ready for publication - any feedback gratefully received


@malcolmsparks good article. As you already said yourself, there are some problems with JWT (, even if you put an expiry date in the token. you cannot lock out a user before the expiry date.


we are still using a durable session store because of that


and then you can just as well use cookies without JWT I guess


@stijn I'm not so against JWT as the author in the article - I quite like it that you can make some claims, and protect them against tampering - that allows you to have state in the cookies which you can trust. Of course, if you want to expire them, you can always do that on the server-side by checking a black-list etc. But the advantage of JWT is that you can get going reasonably quickly without building a stateful session database - I think that's the core advantage. Any time you have a database, you have more things that can go wrong


I think it really depends on your system. But I think the article would do well to have a link to that anti-JWT article too - just so people can make their own minds up


@malcolmsparks I agree, a session store adds quite some complexity. Blacklisting really is the same though as storing the session. I just don't see any other way to go about securing your application when it should be possible to revoke access rights or degrade/upgrade roles


it's the same with cookies though, any client side state you put in there, you can use it to replay requests


and if you don't encrypt your cookie it only gets worse 🙂


If you are interested in a class of sessions/tokens, instead of one specific one, it is not that hard to invalidate. You could do this by changing the signature for instance. We do not use JWT for this, but we have do have a construction similar to this, and it helps us scale


JWT is designed to be stateless. If you're not using it that way, aren't you essentially just using signed cookies?


@dominicm I think that’s true. I guess the main difference is that you can also use it in places where you can’t use cookies, e.g. as a url parameter


@jeroenvandijk: Maybe I should have used the term signed sessions…


JWS is somewhat my preferred "stateful signed session" atm. Which can go anywhere that JWT can.


I think everyone has a point here. I just don’t like articles that say “stop X” as there are valid use cases for all of the approaches


it does make it difficult to correctly implement things like a 'password reset', though, and automatically log out all other sessions


what we do is keep track of invalidated sessions


which really defeats the point of a decentralised token management


@jeroenvandijk The article is perhaps a little angry & sensationalist. But I think he backs up all his points with reasoning.


I have had too many arguments with people that read articles like this, take it very seriously and trying to argue with me I’m doing something wrong. But other than that it is kind of funny 🙂


I think what is missing is context


@jeroenvandijk No doubt I'd change my mind about this kind of article after encountering a few people like that 😛.


I get the impression by "session," he's talking about sites that are: Consumer facing, Log in & modify stuff with auth.


For the purposes of the authentication article, I think it's useful to show people how to read/write JWT cookies, rather than take an opinion on whether it's a good thing to do. The problem is, I don't want to take the reader through the setup of a database, just so I can show them how to do auth in yada


@jeroenvandijk out of interest, what is your use case where the trade-offs of JWT don't apply?


@dominicm I work on a realtime bidding platform, which has a really high scale and certain constraints. Because of the scale it makes sense to use a JWT like concept (custom approach but basically the same) instead of server sessions. The constraints don’t allow use to use cookies or local storage. We have to put data on arbitrary places. Not sure if you get the picture just from this


That said, we might still start to use server sessions (via a keyvalue store), but I wouldn’t say that this is easier or better (at our scale)


@jeroenvandijk Sounds pretty much right for JWT. Those constraints put you into that position more or less.


It's interesting that JWT is easy to start. And necessary at high scale. I'd say that in the middle you want something closer to server-side sessions.


The only reason I see (now) to move to server-side sessions is to be able to store more data and have lower bandwidth usage


Note that I’m just speaking for our use case. It might be less valid for the use case you were talking about


Yes. I've come across corps that can't use GPL because they don't want to enter into the terms of that license agreement. But LGPL allows redistribution.


yada is not EPL. The main reason is to allow redistribution in GPL products