5
In my research I have already found the Object - Navigator, to obtain information relevant to the user’s browser.
However I found nothing satisfactory in this Navigator that I can use to generate a unique identifier of that browser, to store(DB) and recognize in a future access(allow/deny).
In short: It has to be unique for each browser (e.g., Token, MD5).
Gentlemen, do you have any suggestions? or is it something that stands right before the my eyes and didn’t see?
In the front-end nothing will be satisfactory, everything can be manipulated and even if it existed, it would not be reliable for the reasons I mentioned and if someone tells/responds that it is possible to make in the front-end suspicious... Maybe what you need is to create a back-end session and keep it with cookies (almost all languages and/or web frameworks do this).
– Guilherme Nascimento
Exactly as @Guilhermenascimento said, the front end can be manipulated. Has an excellent response in Soen, but it’s like he said, it’s not safe. (If you want I can transcribe it here)
– Sorack
https://github.com/Valve/fingerprintjs2
– Gabriel Katakura
What you want is related to COOKIE.
– rmagalhaess
Thank you all, especially to Sorack and Gabrielkatakura, by showing me the existence of fingerprint, I now have an excellent foundation to continue my project. About the immutability of this fingerprint is the least, because the feature of registering the browser is only to use the server CDN(ex: log in via cli/browser and from there that 'means of access' will be authorized [we can roughly say that fingerprint will be the two-factor of the app]);
– Guilherme Escarabel
@Guilhermeescarabel fingerprint is to analyze the user’s step by step not? Is this all not a cannon to kill ants? What you want seems to me is something much simpler.
– Guilherme Nascimento
@Guilhermenascimento You arrived at the spark of my idea. At first it would be for registration purposes as well as you said, however, wanted to be more audacious. I don’t like the standard form of authentication. Summarizing my idea: "Users have to perform the authentication in order to ask permission that that means of communication can be used to consume the endpoints-protected (regardless of whether it is synchronous or asynchronous)". This abstraction of mine open-source to show how we can change the way we think about common authentication and come up with more thoughtful means.
– Guilherme Escarabel
@Guilhermeescarabel one thing is simply authenticating, another is analyzing the user’s steps, analyzing the steps maybe depends on authentication, but not the other way around, it’s making complex what should be easy, don’t you agree? Unless it’s an almost complete application, but in this case the story changes completely.
– Guilherme Nascimento
@Guilhermenascimento It is a complete application, not only involves using the browser and making some CRUD’s, space does not allow to explain, but involves: commits, stream, command-line. Authentication in this application is and should be checked every 2 seconds. That’s why I use a separate server to handle these checks (with request-per-user limit handling). If you say it’s unfeasible/complex, I understand your concern, and maybe my person is thinking in the wrong way, I’ll take a closer look at how much this is really necessary. But I don’t see an alternate route until then.
– Guilherme Escarabel
I don’t know how complex it is, but I see so many ways around it, I don’t know if it’s worth it.
– Oralista de Sistemas
The most plausible answer I can find for your question would be to use cookies since each browser will have its own and you would join with some hash and have its unique identifier.
– Mateus Veloso