TLDR: You can split the JWT into 3 parts and store them differently in cookies to keep the _payload_ accessible in JavaScript and make the _signature_ inaccessible from the web app.
In the following Stackoverflow thread (https://stackoverflow.com/a/60941643) I described a way to store a JWT in Cookies while keeping convenient to use payload from the Javascript stack (for instance to display the user name).
This is achieved by splitting the JWT in 3 parts (header, payload and signature) and storing it into 3 different Cookies which have different properties. The _header_ and _payload_ would be accessible from the web application while the _signature_ is configured with HttpOnly and therefore unaccessible from the web app. The inconvenient of this method is that you have to reconstruct/concat the 3 parts server side.
Disclaimer: it's actually an experiment which has for purpose to get the better of both world and it has not been tested from security standpoint.
I promised myself to never-ever answer the "CRUD vs HTTP verbs" topic. I could not resist.
It is a huge shortcut to map CRUD operations to HTTP verbs POST, GET, PUT, DELETE. By the way, the definition of HTTP verbs defined in the HTTP RFCs (from RFC 1945 to RFC 7231) and the original thesis from Roy Fielding about REST (which is defining REST principles as an architectural style) never talk about one-to-one relationship between CRUD and PUT-GET-POST-DELETE.
While I understand that it might be confusing without deep-diving in long-long-lectures, the last RFC explains clearly what is the purpose of each HTTP verb including the difference between PUT and POST:
The fundamental difference between the POST and PUT methods is
highlighted by the different intent for the enclosed representation.
The target resource in a POST request is intended to handle the
enclosed representation according to the resource's own semantics,
whereas the enclosed representation in a PUT request is defined as
replacing the state of the target resource. Hence, the intent of PUT
is idempotent and visible to intermediaries, even though the exact
effect is only known by the origin server.
Therefore it would be perfectly valid to "create" a resource with both PUT and POST methods as well as "update" another one with, also, PUT and POST. It is actually even clearly stated with a few examples in the RFC. For instance in POST definition:
Appending data to a resource's existing representation(s).
I used to defined PUT and POST requests according their characteristics: the first one is idempotent, the second is not ... but could be.
Therefore, in my understanding, it is perfectly valid to perform an "upsert" (insert or update) to a resource which doesn't exist yet but for which you already know the URL, it is indeed idempotent. For instance:
PUT /resources/xyz
A last piece of evidence is the first line of PUT section in RFC 7231:
The PUT method requests that the state of the target resource be
created or replaced with the state defined by the representation
enclosed in the request message payload.
I hope it helps to clarify a little bit the topic.
Do you have any references to documented, truly REST APIs? In your experience, what (pragmatic) shortcuts were needed to veer from (some definition of) "pure" REST?
IMO Stripe API[^1] is following well the REST principles and constraints. Btw, if I well remember, they are not using PUT at all while they obviously allow users to update some resources.
They implemented an "Idempotency-Key" header that you could maybe call a "shortcut". Although it's not really deviating from HTTP standards. I guess it was easier and more pragmatic for Stripe and users to implement an "Idempotency-Key" header instead of duplicating each POST endpoint with PUT and PATCH methods since they also allow partial updates. I guess (again) that they would also have to use/implement additional header (such as ETag or If-Match) to replicate current "Idempotency-Key" header behavior.
Disclaimer: This last paragraph is full of assumptions and I most probably miss a lot of internal details from Stripe API.
I own a ThinkPad X1 Yoga Gen 6 with a 11th Generation Intel® Core™ i7 and an integrated Intel® Iris® Xe Graphics. I'm not playing games. I use an external "5K2K" LG monitor (basically 2x 4K monitor) through Thunderbolt 4 port.
Huh, if anything the common argument is that POST is not idempotent by default (and thus isn't cached, needs consideration on automatic retries on errors (e.g. browsers will ask you if you want to send again, proxies can't auto-repeat it), ...), and then lots of advice how to structure your APIs so it is. Because spec very clearly doesn't guarantee it to be idempotent, but you can of course implement your specific application so it uses it in an idempotent way.
I think many people argue that it should be because of network and protocol properties.
http://home.here/setlighton > http://home.here/togglelight. If the answer gets lost and the command is repeated, you have an unknown state of the light in the second case, but both requests are perfectly valid of course.
Actually there is a missing alternative to Mapbox, Google Places and Geocode Earth. As they explain it this blog post, Algolia Places relies on OSM Open Source community to maintain accurate data. Since it's not anymore a business for Algolia, they could Open Source their software (API, user-agents and tooling) and let an Open Source community maintain the software. Not only the data from OSM.
It would be a nice sign from Algolia towards their customers.
IMO it might be a good idea to store binary assets in Git from a "history management" point of view.
However it's a mess when you have to deal with a lot of huge files. Not especially because of bad-habit but because it's hard to manage on day-to-day and you will face a lot of issues.
One of the issues I got recently is the time required to switch between branches (if LFS-tracked files are changing). It is due to the "checkout" and how git-lfs works (see the Github issue). Actually it copies the file... This operation takes time... Instead it could use hard-link or symbolic-link.
> IMO it might be a good idea to store binary assets in Git from a "history management" point of view.
You can't diff them, just see that they changed. If you have versions in the filename of the object that helps but isn't great from an auditing perspective. People change filenames, and if someone alters or tampers with the file it's hard to tell. You might argue that this is also possible if you fetch the file somewhere or install a package and link against it, but you have a better audit trail, packages can (should) also be signed.
I would like to thank you for your feedback. If you still have a little bit of time, here is a quick survey to get more feedback about your needs! https://ku.ag/6dmohc20fvnd
In the following Stackoverflow thread (https://stackoverflow.com/a/60941643) I described a way to store a JWT in Cookies while keeping convenient to use payload from the Javascript stack (for instance to display the user name).
This is achieved by splitting the JWT in 3 parts (header, payload and signature) and storing it into 3 different Cookies which have different properties. The _header_ and _payload_ would be accessible from the web application while the _signature_ is configured with HttpOnly and therefore unaccessible from the web app. The inconvenient of this method is that you have to reconstruct/concat the 3 parts server side.
Disclaimer: it's actually an experiment which has for purpose to get the better of both world and it has not been tested from security standpoint.