Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

inconsistency in chatroom ID generated at client side #39

Open
adhyay2000 opened this issue Oct 16, 2020 · 7 comments
Open

inconsistency in chatroom ID generated at client side #39

adhyay2000 opened this issue Oct 16, 2020 · 7 comments
Assignees
Labels
bug Something isn't working help wanted Extra attention is needed

Comments

@adhyay2000
Copy link

Since the chatroom generated on new user login are generated at random. there may occur a clash, In such an event two users may land up in the same chatroom without explicitly joining. To create such a condition try replacing the function randgene in cnew.py to give a constant chatroom ID. Possible solution can be generating the chatroom ID from server side. Please correct, if I am wrong.

@gridhead
Copy link
Owner

Possible solution can be generating the chatroom ID from server side. Please correct, if I am wrong.

That is a very intelligent solution to the problem. We would want to do that so that the server would create and send an ID which has not been created before. Albeit the chances of having a clash is very small (about 1 in 4,294,967,296) but it is never zero. This is a valid issue. Would you want to work on it?

@gridhead gridhead added bug Something isn't working hacktoberfest Contribute to the notion of open-source this October! help wanted Extra attention is needed labels Oct 16, 2020
@adanielpincab
Copy link

A possible solution could be changing the ID generation algorithm. Maybe using, for example, sha256 for generating new ids?
Of course that would make the chatroom id a lot more tedious to share, but it would lower the clashing probabilities by a lot.

@gridhead
Copy link
Owner

I had that concern previously too. The uniqueness of SHA256 is impressive (about 1 in 340,282,366,920,938,463,463,374,607,431,768,211,456) but this comes at the cost of having to share a 32 characters long string as the chatroom identity. Already, the Fernet password is nearly as long so we could do with some lesser length but greater control at the server's end.

@adhyay2000
Copy link
Author

Possible solution can be generating the chatroom ID from server side. Please correct, if I am wrong.

That is a very intelligent solution to the problem. We would want to do that so that the server would create and send an ID which has not been created before. Albeit the chances of having a clash is very small (about 1 in 4,294,967,296) but it is never zero. This is a valid issue. Would you want to work on it?

Yes, you can assign it to me

@gridhead
Copy link
Owner

There you go. @adhyay2000. I have assigned this issue to you.

@adhyay2000
Copy link
Author

I have modified the code to have a server side verification and registration. The server also maintain a list of available chatrooms that can be used to restrict the same named chatroom.

@adhyay2000
Copy link
Author

please review the code and provide feedback.

@gridhead gridhead removed the hacktoberfest Contribute to the notion of open-source this October! label Nov 1, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working help wanted Extra attention is needed
Projects
None yet
Development

No branches or pull requests

3 participants