If the domain name is in the cookie value then that can't be used when submit another request from another domain. Yes you can configure the dns to bypass that, but at that point it is also pointless for CSRF.
Not to be rude, but from your comments you don't appear to understand what the CSRF vulnerability actually is, nor how attackers make use of it.
Cookies can still only be sent to the site that originally wrote them, and they can only be read by the originating site, and this was always the case. The problem, though, is that a Bad Guy site could submit a form post to Vulnerable Site, and originally the browser would still send any cookies of Vulnerable Site with the request. Your comment about "if the domain name is in the cookie value" doesn't change this and the problem still exists. "Yes you can configure the dns to bypass that" also doesn't make any sense in this context. The issue is that if a user is logged into Vulnerable Site, and can be somehow convinced to visit Bad Guy site, then Bad Guy site can then take an action as the logged user of Vulnerable Site, without the user's consent.
React is the most inefficient in terms of performance (after imgui); it recomputes everything on every event like mousemove. It was probably made for simple forms with tens of variables.
I can understand the point, and the fact that in virtual dom implementations you in general specify the state -> view mapping and don't need to distinguish between first render and updates.
However, practically and personally I find working with signals way simpler, and that is even without considering the debugging experience.
The biggest downside of knockout is that it parses the template from the dom, and the template is rendered as dom until first execution. Then that it eval it's bindings. I suppose tko should help with those issues but seems kinda dead.
Knockout reactivity primitives are also a lot more naive then modern signals implementations.
What benefit could one possibly get by farming karma on site like hacker news. It's not like one can gather followers or something. I'm always mystified by folks who do this. Would love to understand the motivation.
Having multiple high karma accounts is useful in astroturfing, as moderators are (rightfully) more lenient on established community members than new accounts.
Same thing is widespread on reddit, usually for pushing specific products/projects/organizations into the limelight. Landing on the frontpage of reddit/HN drives huge amount of traffic, so obviously "optimizers" learned this, and started priming accounts for future vote-rings and what not, but they need to mix in real-looking content between the pushes so the accounts don't get banned.
<script> parses its contents as text, whereas <template> parses as DOM. This means you don't have to escape `<`, just `</script>`.
Myself and some browser engineers been working on proposals to allow for inline modules, including JSON, that are importable into other modules via regular import statements.
This is why I recommend the "-json" type - so it doesn't collide with a future native "json" type.
My understanding is that in implementations any unknown type creates a "data block", which is just unprocessed text.'
I wouldn't use application/json just in case browsers start supporting that and it has different semantics than whatever custom thing you might do, causing a webcompat issue when the native feature rolls out.
Although with JSON, it's pretty unlikely that there would be any differing semantics. JSON modules in JS are just JSON blocks with no special additions and no named exports. That's what inline versions would be as well.
But wouldn't a subtype like `mytype` in my example (`application/mytype+json`) still be be a valid mime-type and still avoid your concerns? I've used these before.
I can imagine if it's deeply nested data, your markup might get complex, but the structure of the HTML doesn't have to mirror the JSON. There's other examples here which might illustrate more how this can look: https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/...
Thank you. I was looking at a generic way to pass configuration data to custom elements where I cannot know the shape in advance, since another dev can have different requirements. I support data attributes for simple types but i was wondering if allowing arbitraty json objects via other means could be feasible.
Since JSON is a subset of JavaScript, you can just use a script element, and including the json mime type certainly doesn't hurt:
<script type="application/json" id="myJSONData">
{
"name": "John Doe",
"age": 30
}
</script>
<script>
const data = JSON.parse(document.getElementById('myJSONData').textContent);
console.log(data.name + " is " + data.age); // John Doe is 30
</script>
Note: The JSON data must exist literally within the script element. If you try using a src attribute to request it from elsewhere, the response will not be available via textContent or any other mechanism [0], and at that point you just need to fetch/ajax/xhr it.
That article was pretty complicated; I appreciate the historical understanding but frankly web legacy is too complex to bother with "why" too much, in the end so many things just don't make sense and are historical accidents.
That's a helpful summary of what's necessary to make JSON safe to embed in script tags.
I agree the "why" is too long of a story, an accumulation of supposedly logical decisions that led up to the ball of quirks. It's too much to remember. Exactly the kind of thing that should be delegated to a specialized function made and maintained by experts.
I wonder if the browser would attempt to validate the contents of a script tag with type json, versus treating it as a blob that would only be validated when parsed/used. And any performance overhead at load time for doing so. Not at a machine at the moment so I can't verify.
How so? I don't remember ever having seen issues with this. If anything CSP steers you towards this (instead of inline scripts directly assigning to JS variables)
CSP blocks execution/inclusion, but since json does not execute and any json mimetype will not do execution there is no problem.
Any CSP-allowed other script can read that application/json script tag and decode it, but it is no different than reading any other data it has access to like any other html element or attribute.
For my portfolio (miler.codeberg.page) and the refactor&redesign I'm doing of it (that I hope to finish soon!), I feed some <template>s with data coming from a json that acts like kind of a database. I feel the process of querying nodes and setting their data is still a bit rudimentary in plain JS and it should be a pain in the ass for huge datasets or lots of nodes, but at least with modern JS it is not necessary to fetch the json with a XMLHTTPRequest or something - it can work importing it like a regular JS module, so at least there's that.
You can use graalvm AoT. It mitigates the issues for some use cases when you need to use Java.
Standard Java on Lambda has not been feasible for me either
