rmedaer

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.

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.

[^1] https://stripe.com/docs/api

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.

   Appending data to a resource's existing representation(s).

   PUT /resources/xyz

   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.

No lag at all on Firefox. Still have some unsupported GPU related features on Chrome.

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.

Really happy with this setup.

https://developer.mozilla.org/en-US/docs/Web/HTTP/Status ?

Really? Reading blogs, articles, etc. 99% of them say "POST is idempotent". They never say "but it could be".

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.

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

Kind regards,

You got the point.

Hi Jugurtha,

Actually a REST API is already ready. I consider to offer premium services (API, link management, bulk generation, etc.)

Could you send an email to info@ku.ag in order discuss more about it ?

Kind regards,

Every string encodes to the same amount of “squares” (...)

Actually the size of QR Code doesn't depend only on length of the string but also on charset used.

For instance, the URLs generated at bit.ly are case sensitive, to encode the qr code you have to use "binary" input mode.

For KUAG I'm using "Alphanumeric" input mode, it reduces the size of the QR code I'm generating however I restricted to a smaller subset of character.

I understand it looks like a paradox; but a bit.ly shortened url leads to a bigger QR code than KUAG (even if the string is longer)

See https://en.wikipedia.org/wiki/QR_code#Storage for more details.

Note: the shortened url I display is 'lowered' for esthetical reason.

Edit: I forgot to mention the error-correction. But I don't think it's fair compare with other shorteners if they are not using the same error-correction level.

Would you be interested to read a blog post about how it works?

I consider to write a few articles about each part of the project... if there are people to read them! ;-)

It generates the smallest QR Code possible (Version 1; size 21×21).

Other URL shorteners generates bigger QR code (usually version 2 or 3)

Hi masukomi.

Currently it's still a side project (started a few days). My plan included the following phases:

  1. Idea + POC (solved technical issues) => Done
  2. Build a MVP => Done
  3. Get some feedback and see if there is any interest. => Here we are!
  4. Based on feedback, add (premium) features but keep the basic service for free.

So feel free to share your ideas, I would enjoy to answer and challenge them!

Furthermore I plan to write a small survey to get more feedback.

About the "Open Source" part: as a regular FOSS contributor, I do not exclude to publish sources. However, publishing sources means maintaining them. And I don't want to maintain a useless project. So currently I don't want to publish them.

Hope it helps you to understand my strategy for this new experience!

Right! Currently there is no plan to remove shortened URL. Meaning that the service keep shortened URL indefinitely.

The shortened URL contains 25 characters. Actually it could be smaller but the goal is to generate the smallest QR code. To do so, a restricted set of characters is used. The result is a small QR code version 1.

There is currently no limitation on input URL size. However you might reach some limitation (> 4096bytes) due to the current proxy.

Thanks quaffapint to raise this point. To be honnest, I hesitated to add this question in the post. Indeed HPACK could partially solve the issue. But as you said, it requires HTTP/2. Btw, HPACK is well explained here: https://developers.google.com/web/fundamentals/performance/h...

I tried in this post to not talk about the "transport". Indeed JWTs can be used with HTTP/1.1, HTTP/2 or even SIP. Furthermore HPACK maybe disabled in some cases. Here is what the RFC 7541 (HPACK) says about Authorization header (https://tools.ietf.org/html/rfc7541#section-7.1.3):

  "An encoder might also choose not to index values for header fields that are considered to be highly valuable or sensitive to recovery, such as the Cookie or Authorization header fields."

I edited my article with a link to the RFC of JSON Web Tokens, which is for me the first result on Google or DuckDuckGo when I search "JWT".

I see that you have a lot of scopes (https://github.com/difi/felleslosninger/blob/ad9ef79b4fef61f...). Especially from 3rd parties (https://integrasjon.difi.no/scopes/all https://integrasjon-ver2.difi.no/scopes/all)

Do you have some statistics about that ? For instance, do you know how many scopes are usually requested, on average ?

need to be some degree of agreement and coordination between token producers about what a particular scope string means & agreement between different services (...)

I agree with you on this point. Actually there are already some "common" scopes, for instance OpenID Connect defines some scopes ("openid", "profile", "email", ...): https://openid.net/specs/openid-connect-core-1_0.html#ScopeC...

However I don't think (to be confirmed) there is a IANA registry for scopes (source: https://www.iana.org/protocols)

But there is one for claims in JWT:

https://www.iana.org/assignments/jwt/jwt.xhtml#claims

Hi shoo, thanks for your feedback. At this point in time this is only a proposal. A proposal which needs to be challenged. So thanks again for your useful feedback.

Indeed the goal is to limit the size of JWT tokens. I can't tell you if it really improves the performances for now. I already started a spreadsheet to compare the bitmap scope list against the space-separated list. Although I need some real examples and metrics to do a relevant analysis of the impact.

One of the questions you raised is about the scopes commonly used. Should we defined a shared dictionary/registry ? Maybe. I would propose to open an issue on Github to discuss about that. Here it is: https://github.com/rmedaer/rmedaer.github.io/issues/2

If there is more interest in this proposal, I would propose to create a dedicated repository where ~~I~~ we could discuss, compare and challenge it.

Kind regards,

Here I'm talking about the value of one particular claim: `scope`. If you identify each scope by only one character it would be limited to the size of your alphabet.

If you talk about claim names, they basically aim to be short. For instance, claims defined in RFC7519 Section 4.1 (https://tools.ietf.org/html/rfc7519#section-4.1) are only 3 characters long. As explained in the same section:

  "All the names are short because a core goal of JWTs is for the representation to be compact."

Understood! The name is inspired by "Open*" projects. For instance OpenAPI. The goal of this project is first to design a specification format for APT repositories like OpenAPI is doing for HTTP APIs.

I have to admit that it is not the best name ever. I'm "open" to any better proposal. Feel free to open an issue with the best meaningful name idea you have!

Managing, organising and publishing APT repositories became a nightmare for us as well. That's why OpenAPT is alive.

It moves APT management from script paradigm to state description paradigm. Indeed with OpenAPT, you don't have to write command lines anymore but instead you describe the state you want to achieve. Just like Ansible does.

Btw, it's a brand-new project. If documentation is lacking, feel free to open issue(s). We will be happy to help you.

What do you mean by "closed apt" ?

I'm going to build a small online service with only one product and a subscription fee by month. I had to compare the Payment Gateways to know which one fit my needs.

To do this comparison, I made a small spreadsheet which could (maybe, or not) help you. Here it is: https://docs.google.com/spreadsheets/d/12-sWEe-gsoGm0kT5LMcM...

Feel free to add comments if you find any issue.

It might be interesting to answer the same questions for `git-crypt`!

I also listen to `git-secrets`... but I don't know much more!

Replying to AN:

You can now use systemd to configure it (v243): https://github.com/systemd/systemd/pull/12441

Since yesterday systemd v243 is in debian/bullseye (testing): https://tracker.debian.org/news/1079640/systemd-243-5-migrat...