@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?

@magicMirror
"CORS will prevent the injected html from loading a resource from the attacker server" - No it will not. Broser will send option to attacker server and server will provide headers that will allow browser to access it.

What is this shit supposed to protect, if header can be set manually to 'Access-Control-Allow-Origin': '*'.

Looks like they have created this crap just to make development harder, because otherwise I dont see how it can do anything useful.

Can anyone tell any example on when CORS can really help, because so far I haven't read any reasonable explanation.

@Ison
Well it has sidebar for bookmarks I am used to because I came from Firefox. And in the same time it is based on Chromium so it basically works, compared to what Firefox has become nowadays.

@Oktokolo
Storing passwords in a password manager is the same as having one password for all services and in addition showing it to 3rd party.

@sbiewald
Good point, I've answered to A-B above: one password+mfa for secure accounts and other password for online stores is enough.

No need to create different passwords for every resource, and if they force you to - they force you to write it somewhere, or forget it, thus decreasing security and stability instead of increasing it. And of course adding 333 at the end of your pass to meet stupid 15 min-length restriction will not help you in case of C.

@C0D4
Different passwords for online banking accounts will not help in case someone knows them. If someone steals one of your passes he will steal them all.

Password manager is the same one passwrod for everything, just sent to 3rd party people instead of remembering it - total crap.

MFA is good stuff, and it is enough to secure your data, again, the more tools you use to remember billion passwrods you create the more the chances that they will leak or you will forget them.

Different passwords is an illusion of safety, nothing more.

One password for secure data + MFA, and a diffferent one for registering on untrusted resoruces is more than enough.

@tonypolik

1. Forcing me to do anything is bad
2. No, using different password everywhere is bad because it is impossible to remember all of them and you will have to store your passwords somewhere. That "somewhere" can be accessed by hackers and your passwords will be lost.
3. The best place for storing passwords is in your head, thus using one/two passwords is more secure than using different ones.

No there is no way

I am also sure that framework that uses
<div> inside <div> inside <div> inside <div>
to achieve something as easy as flexbox layout is shit. So bootstrap is a legacy shit that should be avoided, at least for layout purposes.

@Kandelborg You, guys here are so polite, I like that ;D

Actually, of course I'm always educating myself, but when it is possible to kill your production app just by trying to update dependencies - it is a real pain in the ass. (and it almost always does so)

Or another example: you were running "npm install [list of packages you project requires]" yesterday, and then just started to write your code.

But today it is not working anymore! Something in a list of 15-20 dependencies causes it to fail. And you either spend hours of finding what, or just end by copy-pasting your old config to stick to older versions and never update.

That is a frustration indeed, and it continues to happen.

Thank you, guys, again for advices, your help is much appreciated, now I have plenty of stuff to read ;D

@thatsnotnice

What you write sounds very sensible.

I'm starting 'Good parts' immediately

Thank you a lot.

@thatsnotnice

Yeah I've heard about that book as well, but it is even older (2008 vs 2011) and shorter (172 pages vs 1096) will that really be enough for deep understanding of the language?

@ThatPerlDeb because the owner of that website is a retarded cocksucker, of course

That site is an example, when the retarded client makes developer to use JavaScript to do evil things, you can use a plugin to disable JS on their site and continue watching though ;D

@c3ypt1c yes, you are right, it does not make it a bad browser, it makes it a piece of shit browser

by edit I mean fucking full edit, not only rename, is that so hard?

@c3ypt1c okay, sir, I should write FULL_EDIT == RENAME && MOVE && SORT. In case of firefox shit we have TRUE && TRUE && FALSE here so FULL_EDIT === FALSE

I will express myself more clear on my next rant, thanks.