it is easy, anything that can be used to break your nose is real and vice versa

@Lensflare

I see that you are a 20iq dumbass, that can not calculate time from timestamp to current date (and probably even don't know what current date is) but lucky not all people are like you

@Lensflare

bullshit are people and projects that utilize this useless garbage

@Lensflare

"A relative timespan is easier to process" - for whom does the fuck it is easier? For 20iq monkeys maybe, and even with that I am not sure.

@ScriptCoded

They would never become obsolete if those retarded fucks dont close the thread and it can be UPDATED!

go to russia then, moron, but don't forget that the police will beat the shit out of you there

@Parzi

mac does that natively with no problem, look my comment above

If anyone is interested, there are tools for showing folder sizes in

Windows - FolderSize free tool that works intuitively perfectly

Linux - Krusader free tool that has calculate size (ctrl+q) option for currently open directory

Mac - surprisingly has native support for that in finder View->Show view options->Calculate all sizes

Calculating all folder sizes for root of 256gb ssd takes around 1 minute, which is fast. Try to use them and you will be able to delete gigabytes of cache, logs and other garbage that any OS/app stores in mass on your drive.

@Lensflare

3rd party malware sponsored by OS makers

@fullstackclown

I once used next and will never do that again. Their routing was made by a person even more insane than react-router suckers

@fullstackclown

Your examples are not a router at all, just a couple of navigation functions.

If you ever try to build a web application using React that has at leas 50+ pages, some of which require authorization to be visited, some are displayed under nested routes, some use parametrized routes - you will see why it is absolutely necessary to have a routing library.

Also the big apps require lazy loading, that is technically possible to implement without a routing library, but you will not be able to efficiently manage it, especially when the app will grow larger.

Btw I've drilled their shit documentation as well as useless github examples and found the only place where they explain how nested routes work in new shit version of their shit library.

It could be found only in the migration guide. Absolutely retarded.

https://reactrouter.com/en/main/...

@retoor

"Ask chatGPT"

I've tried, even chatGPT is not possible to understand their shit documentation. It messes v5, v6 and who knows what else.

https://linkpicture.com/q/...

@lorentz

Does React Navigation work only with React Native? What about web apps?

I also remember those stupid cocksuckers writing a blog post where they were happily introducing nested routes only inside child route's component.

Thus breaking v4 compatibility.

Now in v5 to v6 migration guide they proudly say that there is no need in that, and you can again define all routes in one place, what a perfect example of self-fuck.

@electrineer

I see, looks like you either use laptop olny for watching movies or a mutant that has 7 fingers instead of 5. There is nothing good in additional button if it brings pain instead of usability. ;D

@fraktalisman

I use 3 languages to type. And code a lot. And still see no use in that useless bullshit button that decreases shift length.

So people that were "optimizing" this are just fucking morons, this is actually counter-optimization.

@Burgundxyz

Yeah that hook looks ugly, but it is required for functional components to be able to use Ref on them. With class components code looks better.

This is of course a "+" for the first method

But my question is more about the idea of calling child method from parent, not the implementation.

@hjk101
"a.site loads a script from b.site or runs otherwise injected js than it runs on a.site and thus has access and can send it wherever"
- oh my... I didn't thought about that, that would definitely break the isolation! Thank you for the explanation, a lot.

I wanna say thx to you all guys for the talk esppecially for
@Fast-Nop and @arekxv
Now I understand that it should be called SOP (and CORS is a mechanism to bypass SOP if needed) and its main idea is that legit browser and legit server can protect the data of a user, that visits "bad" webpage running malicious scripts, from being acessed.
And scripts are possible to do such harm because cookies work like shit. SameSite cookie property can help that as well, but it arrived later than SOP.

@Fast-Nop
Damn ads are pain indeed

@hjk101
"One can encode your session cookie for example in POST data, get parameters, and even path"
- How can he do that? Is it possible to access cookies from a.site, for a script running on b.site domain? I think no, how then?

@arekxv
"Also new browsers added a solution for that already. Google chrome forced it two years ago with SameSite property in cookies"
- Yeah I've read about that, looks much better than SOP. Why don't they replace SOP with SameSite property? It solves all of the problems the SOP does, but without so much restrictions. (Why blocking requests that don't send cookies)

@arekxv
Why just don't block browser from sending cookies to cross domain requests rather than completely blocking it from sending any request?

The CSRF attacks you describe could be completely avoided if browser would not attach cookies aquired from a.site to requests made in tab that is showing b.site.

Like it works with local storage, if I never save login information into cookies and store it in localStorage instead, let's consider your example with website that tries to steal facebook information. How can it steal it if facebook auth token is in localStorage of facebook domain and is manually attached to requests made by facebook scripts rather than rely on browser cookies? Isn't that better than inventing SOP that blocks everything even harmless requests?

@Fast-Nop
Thanks.
Why cookies can not be isolated by domain then? Like if I am in a tab that is displaying b.site it is impossible to attach any cookies that were saved by a.site to any requests that tab makes.
Looks like perfect protection to me. We still can load images and other not secure stuff from cross-origin, but no sensitive data that requires authentication can be received from a.site by scripts running on b.site.
Rather than completely blocking browser from making requests we can block it from sending cookies.

@Fast-Nop
"The a.site server in turn cannot block that because it has no way to discern that the script is from b.site, given that it is running client-side and not on the b.site server."
- But server can access headers.origin to determine that, can't it?

"It is not stupid to attach cookies to another tab because cookies aren't even related to any tab."
- That is sad, isolating cookies to tab could protect from CSRF better than everything else I think. What about localStorage? It is tab related, thus I think it could be better to store tokens there and manually attach them when needed, rather than trust that to cookies that are auto attached, thus can be used for actions that require authentication on a.site by scripts running on b.site. Which sounds really bad.

"I think you should read up on the basics of cookies, SOP, and CORS."
- Already done it on MDN, still has a lot of questions, can you suggest any good article/book/video about it?

Thanks for the reasonable replies.

@Fast-Nop
"As long as you're logged in to the banking site, the browser sends the required cookies"

Do you mean that if I have cookies for a.site and script on b.site in other tab sends request for a.site, browser will automatically add all cookies set by a.site to request actually sent from another tab?

If that is thuth - then this is what should be disabled in browser, not actually sending the request. It is stupid to block tool made for sending requests(browser) from doing its job. It's also stupid to attach auth tokens to request that was sent not from the tab that received that tokens.

Also it sounds more sound that server should examine request origin and decide to send sensitive data back or not rather than rely on that browser will not try to access that data.

@hjk101
"Either learn about same origin policy or don't do web development." - looks like you know a lot about web development and same origin policy, now please show an example on how CORS can protect from any kind of attack.

@magicMirror
"Like, being logged in to a banking site, also visiting an unrelated site that was hacked, and presto, the hacked site can use a malicious script to read any data from the banking site." - How would it read any information from banking site? It does not have access to login tokens. Banking site server will reject conenctions with 401

@netikras
"Most of such algorithms protect from bots scanning the internet looking for known vulns. They do not protect from targeted elaborate attacks" - How? can you provide an example?