Interesting find! But honestly I believe it is the job of the implementer to make sure, that the uniqueid actually is (and stays) unique. Thus, when setting up another website as a client of the same jsconnect, then make sure those IDs are unique (using a prefix or something similar).
@HalfCat said:
it is the job of the implementer to make sure, that the uniqueid actually is (and stays) unique.
Precisely. That's the core of the issue here. If you wanna start sending new uniqueids, that's fine, but you need to wipe all the existing connections that have been made first.
Correction to my previous post
It seems that Vanilla already distinguishes unique IDs coming from different sites. While querying the UserAuthentication table, I didn't select all fields and I just spotted ProviderID. This is the ID of the Client which sends the JSON, and I presume that Vanilla uses the pair ProviderID+ForeignUserKey to determine if a User already exists.
Therefore, User IDs generate by another website won't clash, as long as the second website uses a different Client ID (which makes sense).
Conclusion
The issue was the result of a coincidence, due to the reinstallation of a website which uses the same Client ID of a previous setup. Of course, Vanilla cannot possibly know that the Client, who presents itself with perfectly valid data, is instead someone else, whose IDs represent completely different people.
@HalfCat Since Vanilla allows multiple clients, it's its duty to distinguish the IDs received from one or the other client, without mixing things up. In fact, this is what it does (I just didn't notice the ProviderKey field, when I wrote my previous post).
Thanks everybody for the suggestions, I probably would never have figured it out without the help of the Community.
@Lincoln said:
Precisely. That's the core of the issue here. If you wanna start sending new uniqueids, that's fine, but you need to wipe all the existing connections that have been made first.
I think that HalfCat meant that different websites should provide IDs that are unique amongst them, which is not easy (and, often, not possible).
What I was not aware of was that the ID passed by a Client was used to find a User in Vanilla. Since JsConnect requires User Name and Email, I thought they were the ones used to figure out if the User already existed. Since I recreated the Users with the same details, I was expecting them to match forum accounts again, hence the confusion.
By the way, would it be possible to alter the title of the discussion to something like a warning? The issue is not a bug, but I believe it would be worth keeping it to warn people who might make my same mistake.
I altered the title. Just want to give you some thanks for taking the time to work through the issue everyone. Any potential security threat is serious business and having some community support on this front is great for us.
Thanks @Todd. In this case it was a misconfiguration from my side, but it gave me a fright as it was far from obvious. Unfortunately, there is no technical way to make it clear (after all, data was exchanged correctly, although it had a different meaning), that's why having this post as a reference will be useful.
Hopefully, it will save a heart attack to anyone who will make the same mistake (as long as he/she will spend some time searching on the Community first).
Since Vanilla allows multiple clients, it's its duty to distinguish the IDs received from one or the other client, without mixing things up. In fact, this is what it does (I just didn't notice the ProviderKey field, when I wrote my previous post).
I totally agree with this point, you cannot have security based on external factors assumed to be correct. Nobody in their right might would implement something like that.
Answers
Interesting find! But honestly I believe it is the job of the implementer to make sure, that the uniqueid actually is (and stays) unique. Thus, when setting up another website as a client of the same jsconnect, then make sure those IDs are unique (using a prefix or something similar).
Precisely. That's the core of the issue here. If you wanna start sending new uniqueids, that's fine, but you need to wipe all the existing connections that have been made first.
Correction to my previous post
It seems that Vanilla already distinguishes unique IDs coming from different sites. While querying the UserAuthentication table, I didn't select all fields and I just spotted ProviderID. This is the ID of the Client which sends the JSON, and I presume that Vanilla uses the pair ProviderID+ForeignUserKey to determine if a User already exists.
Therefore, User IDs generate by another website won't clash, as long as the second website uses a different Client ID (which makes sense).
Conclusion
The issue was the result of a coincidence, due to the reinstallation of a website which uses the same Client ID of a previous setup. Of course, Vanilla cannot possibly know that the Client, who presents itself with perfectly valid data, is instead someone else, whose IDs represent completely different people.
@HalfCat Since Vanilla allows multiple clients, it's its duty to distinguish the IDs received from one or the other client, without mixing things up. In fact, this is what it does (I just didn't notice the ProviderKey field, when I wrote my previous post).
Thanks everybody for the suggestions, I probably would never have figured it out without the help of the Community.
My shop | About Me
I think that HalfCat meant that different websites should provide IDs that are unique amongst them, which is not easy (and, often, not possible).
What I was not aware of was that the ID passed by a Client was used to find a User in Vanilla. Since JsConnect requires User Name and Email, I thought they were the ones used to figure out if the User already existed. Since I recreated the Users with the same details, I was expecting them to match forum accounts again, hence the confusion.
My shop | About Me
By the way, would it be possible to alter the title of the discussion to something like a warning? The issue is not a bug, but I believe it would be worth keeping it to warn people who might make my same mistake.
My shop | About Me
I altered the title. Just want to give you some thanks for taking the time to work through the issue everyone. Any potential security threat is serious business and having some community support on this front is great for us.
Thanks @Todd. In this case it was a misconfiguration from my side, but it gave me a fright as it was far from obvious. Unfortunately, there is no technical way to make it clear (after all, data was exchanged correctly, although it had a different meaning), that's why having this post as a reference will be useful.
Hopefully, it will save a heart attack to anyone who will make the same mistake (as long as he/she will spend some time searching on the Community first).
My shop | About Me
I totally agree with this point, you cannot have security based on external factors assumed to be correct. Nobody in their right might would implement something like that.
grep is your friend.