rmedaer · HackerTrans

rmedaer

no profile record

Submissions

Prevent Forwarded header spoofing with HTTP message signature

raphael.medaer.me

1 pointsby rmedaer4 lata temu0 comments

Ask HN: PCI-DSS (level 3/4) for a one-man business?

1 pointsby rmedaer4 lata temu0 comments

Ask HN: Is Progressive Enhancement still relevant in 2022?

6 pointsby rmedaer4 lata temu7 comments

Writing a Node.js loader for native CSS modules

raphael.medaer.me

1 pointsby rmedaer4 lata temu0 comments

Another Better Git Flow

raphael.medaer.me

2 pointsby rmedaer4 lata temu0 comments

Attempt to standardize the JavaScript API to encode/decode CBOR

1 pointsby rmedaer5 lat temu0 comments

Yes, a POST can be idempotent, said HTTP RFC editor

1 pointsby rmedaer5 lat temu4 comments

OAuth flow to obtain JWT without user consent

stackoverflow.com

1 pointsby rmedaer5 lat temu0 comments

How to get OAuth access token without resource owner consent?

stackoverflow.com

1 pointsby rmedaer5 lat temu0 comments

BlimpDrive: Stupid-Simple Electric Paramotor

2 pointsby rmedaer5 lat temu0 comments

How to Write an RFC – A Tutorial (2005) [pdf]

1 pointsby rmedaer5 lat temu0 comments

T-Shirt Size Estimation (Agile)

explainagile.com

1 pointsby rmedaer5 lat temu0 comments

Another Successful Git Flow

raphael.medaer.me

2 pointsby rmedaer5 lat temu0 comments

Yet another successful Git branching model

raphael.medaer.me

2 pointsby rmedaer5 lat temu0 comments

Sunset of Algolia Places Feature

5 pointsby rmedaer5 lat temu1 comments

Server Side Includes (SSI)

en.wikipedia.org

1 pointsby rmedaer6 lat temu0 comments

Git filtering mechanism isn't intended to be used the way Git LFS has used it

9 pointsby rmedaer6 lat temu14 comments

Show HN: URL Shortener Optimized for QR Code

52 pointsby rmedaer6 lat temu41 comments

Ask HN: Should I write Terms and Conditions for a free-to-use service?

6 pointsby rmedaer6 lat temu2 comments

Configure Your Sockets with URIs

raphael.medaer.me

2 pointsby rmedaer6 lat temu0 comments

comments

3 lata temudiscuss

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.

4 lata temudiscuss

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

4 lata temudiscuss

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.

4 lata temudiscuss

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

4 lata temudiscuss

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.

4 lata temudiscuss

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

5 lat temudiscuss

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

5 lat temudiscuss

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.

6 lat temudiscuss

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.

6 lat temudiscuss

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,

6 lat temudiscuss

You got the point.

6 lat temudiscuss

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 [email protected] in order discuss more about it ?

Kind regards,

6 lat temudiscuss

> 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.

6 lat temudiscuss

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! ;-)

6 lat temudiscuss

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

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

6 lat temudiscuss

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 in summary; yes it will stay free, I might add some "acceptable" limitations but the goal is indeed to propose additional (non-free) features like well-known services (for instance Gitlab).

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!

6 lat temudiscuss

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

6 lat temudiscuss

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.

6 lat temudiscuss

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."

6 lat temudiscuss

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".