use uuid instead of username for Bitbucket #1945
Comments
|
Agreed. I will work on collecting data about how many Gittip user's will be impacted and in what ways. |
|
Any idea about how to approach this? We have in general no way of |
|
Bitbucket asks users for their email addresses. I don't know if we can get those addresses. I want data on how bad the problem is. How many users are only setup with Bitbucket? Of those, how many have tips? how many have a balance? If the list of people is small, we can try to track those people down one at a time. If the list is long, we may have to take a batch approach, possibly kicking out users 😦. |
|
Some basic Gittip numbers for BitBucket OAuth.
|
|
What about active users? (either giving or receiving) |
|
I haven't gotten to active users. Of the 33 with OAuth tied to a nonexistent BitBucket user, 11 have no other OAuth set and 22 do have another OAuth setup. I'm going just blow away those 22 ties, since that appears to be a safe thing to do. (Once I've cleared the links, I'll publish that list here.) |
|
I just disconnected these 22 ties to BitBucket accounts that do not exist:
|
|
1181 does not seem like a number we can contact by hand 😦. |
|
The Bitbucket API does not give out an email, but then, it doesn't give out account creation date either, when their web site does. I haven't dug around on their web site to see if I might be able to find email addresses there. Git commits will have email addresses, but it may not always be clear which commit (and email addresses) are associated with an account owner and some accounts may not have any commits. |
|
The eleven Gittip users which only have OAuth to a nonexistent Bitbucket user have never had incoming tips nor outgoing tips and no Stripe or Balanced financial tie setup. So, these users present no risk, they are only messy. |
|
There is a possibility to "Send message" once you are logged in the I also am wondering if we just should drop the whole bitbucket On 28 January 2014 11:48, Bruce Adams [email protected] wrote:
|
|
@bruceadams What are your thoughts on the way forward with this? I am willing to try the "send message" thing to notify bitbucket users (to attach another account). The next thing would be #900. BTW: Bitbucket allows renames (nkistner is now most likely wyze but we have now way of confirming). |
|
Everyone's periodic reminder that Bitbucket auth is unfixably broken, and that we need to remove it. |
|
Top. |
|
I've added the |
|
This has been open long enough that we need to go through the exercise again. |
|
Some basic Gratipay numbers for Bitbucket OAuth.
|
|
We're going to have to drop some users entirely. Anyone with Bitbucket as their only signin method will no longer have a Gratipay account. We will drop some people who are giving through Gratipay. We will drop some people who are receiving through Gratipay. The real hard part will be dropping people who have a balance on Gratipay. We should try our best to notify people who are giving, receiving, and/or have a balance on Gratipay. We can do this by trying to find emails for people, and then beyond that we'll just have to depend on a blog post about it. |
|
Question: Are we going to keep Bitbucket as a non-sign-in auth method? I say no. With no immutable ID there's no question but that those connections are going to degrade over time as people change their Bitbucket usernames. I say we drop Bitbucket entirely. |
|
So how many people in each category are we going to have to drop?
|
|
We have 39 users that are either giving or receiving or have a balance, and can only sign in using Bitbucket. select e1.platform, e1.user_name, p.username, p.balance, p.receiving, p.giving
from elsewhere e1
left join elsewhere e2
on e1.participant = e2.participant
and e1.platform = 'bitbucket'
and e2.platform in ('twitter', 'github', 'facebook', 'google', 'openstreetmap')
join participants p
on e1.participant = p.username
where e1.platform = 'bitbucket'
and e2.platform is null
and (p.balance + p.receiving + p.giving) > 0
order by p.balance desc
; |
|
36 if we exclude suspicious accounts. drop table if exists only_bitbucket;
create temp table only_bitbucket as (
select e1.platform, e1.user_name, p.username, p.balance, p.receiving, p.giving
from elsewhere e1
left join elsewhere e2
on e1.participant = e2.participant
and e1.platform = 'bitbucket'
and e2.platform in ('twitter', 'github', 'facebook', 'google', 'openstreetmap')
join participants p
on e1.participant = p.username
and p.is_suspicious is not true
where e1.platform = 'bitbucket'
and e2.platform is null
and (p.balance + p.receiving + p.giving) > 0
order by p.balance desc
);
select * from only_bitbucket; |
|
30 if we exclude unclaimed accounts: drop table if exists only_bitbucket;
create temp table only_bitbucket as (
select e1.platform, e1.user_name, p.username, p.balance, p.receiving, p.giving
from elsewhere e1
left join elsewhere e2
on e1.participant = e2.participant
and e1.platform = 'bitbucket'
and e2.platform in ('twitter', 'github', 'facebook', 'google', 'openstreetmap')
join participants p
on e1.participant = p.username
and p.is_suspicious is not true
and p.claimed_time is not null
where e1.platform = 'bitbucket'
and e2.platform is null
and (p.balance + p.receiving + p.giving) > 0
order by p.balance desc
);
select * from only_bitbucket; |
|
|
I searched for |
|
Indeed, we added that a few weeks ago, but our doco is lagging behind. That is a public field that you should use. It's on repos too (though you wouldn't care as much about that I'd think). You can substitute usernames and uuids in URLs. These URLs are equivalent: https://api.bitbucket.org/2.0/users/evzijst |
|
The curly braces let us distinguish between a UUID string and a username that looks like one. Curly braces are illegal in usernames (you will have to urlencode them, which I omitted in my previous comment for clarity). |
|
Awesome, thanks @erikvanzijst! Congrats on rolling out |
|
Here's a little script to take a list of usernames on stdin and spit out import requests, sys
for line in sys.stdin:
username = line.strip()
response = requests.get('https://bitbucket.org/api/2.0/users/' + username)
print response.status_code, username
sys.stdout.flush() |
|
We have 4,278 non-team Bitbucket accounts on file. Of these 4,211 are |
|
Okay! Here's how I suggest we proceed:
|
We should also look at whether a Bitbucket-connected-account has a funding instrument attached (credit card, bank account, PayPal, bitcoin). |
|
Of the 1,521 Bitbucket-only Gratipay accounts, there are five with bitcoin addresses on file, one with PayPal, two with bank accounts (both working), and 34 with credit cards (24 working). That's 42 accounts total (there's no overlap amongst those four categories). |
|
Nine of the 1,521 have already been closed by the account owner. |
|
Should we put some sort of notice under "Connected Accounts" with a link to our blog post about this? It would only be relevant for people who had another account connected. |
chadwhitacre
changed the title
|
It is probably lazyness that speaks over me that it is probably not worth |
More trouble than it's worth. |
|
I.e., +1 @techtonik. :-) |
|
I'm thinking of doing the |
|
Now for a blog post. |
|
Post revised. I took out the update re: Facebook and Google+. We'll do that in a separate post. This is significant enough to warrant its own post. |
Some of those |
|
We only have three email addresses on file for the 50 non-suspicious accounts that are Bitbucket-only and have giving/receiving/balance or a funding instrument. |
|
Used this for some figures in the blog post: drop table if exists only_bitbucket;
create temp table only_bitbucket as (
select p.username, e1.user_name, p.email
, p.claimed_time, p.is_suspicious, p.is_closed
, p.balance, p.receiving, p.giving
, p.last_ach_result, p.last_bill_result, p.paypal_email, p.bitcoin_address
from elsewhere e1
left join elsewhere e2
on e1.participant = e2.participant
and e1.platform = 'bitbucket'
and e2.platform in ('twitter', 'github', 'facebook', 'google', 'openstreetmap')
join participants p
on e1.participant = p.username
where e1.platform = 'bitbucket'
and e2.platform is null
order by p.balance desc
);
select count(*) from only_bitbucket;
select count(*), sum(balance), sum(giving+receiving) from only_bitbucket
where ((giving + receiving + balance > 0)
or last_ach_result is not null
or last_bill_result is not null
or paypal_email is not null
or bitcoin_address is not null)
and (is_suspicious is not true)
;
drop table if exists not_only_bitbucket;
create temp table not_only_bitbucket as (
select p.username, e.user_name
, p.claimed_time, p.is_suspicious, p.is_closed
, p.balance, p.receiving, p.giving
, p.last_ach_result, p.last_bill_result, p.paypal_email, p.bitcoin_address
from participants p
join elsewhere e
on p.username = e.participant
and e.platform='bitbucket'
and e.user_name in (
select e1.user_name
from elsewhere e1
join elsewhere e2
on e1.participant=e2.participant
and e1.platform='bitbucket'
and e2.platform in ('twitter', 'github', 'facebook', 'google', 'openstreetmap')
group by e1.user_name
)
);
select count(*) from not_only_bitbucket;
select count(*), sum(balance), sum(giving+receiving) from not_only_bitbucket
where ((giving + receiving + balance > 0)
or last_ach_result is not null
or last_bill_result is not null
or paypal_email is not null
or bitcoin_address is not null)
and (is_suspicious is not true)
; |
|
None of the 24 true orphans have any giving/receiving/balance. select p.username, e.user_name, p.giving, p.receiving, p.balance, p.last_ach_result, p.last_bill_result, p.paypal_email, p.bitcoin_address
from elsewhere e join participants p on e.participant=p.username
where platform='bitbucket' and user_id not like '{%'; |
|
IRC re: blog post. |
|
@whit537 I should mention another API that is still awaiting documentation. I'm assuming that to obtain the Bitbucket username after the OAuth dance, you hit https://api.bitbucket.org/1.0/user and look at the username and then hit https://api.bitbucket.org/2.0/users/evzijst to pull out the Aside from the fact that that There's a 2.0 version of the |
|
@erikvanzijst Thanks, yes! We're using the 2.0 user endpoint. :-) |
|
Sweet! P.S. Terribly minor, but that the former has the tiniest race condition that the |
|
@erikvanzijst Cool, thanks. I think we're constrained by our |
Update: Bitbucket recently rolled out
uuids for their user API, so we can switch to that instead of dropping them. See below.In the long run we're considering dropping all authentication via OAuth and only allowing password authentication (#1052). In the short run we need to drop Bitbucket as an auth method, because Bitbucket gives us no immutable user id, so if someone deletes their Bitbucket account, an attacker could create a Bitbucket account with their username and take over their Gittip account. @bruceadams demonstrated this here: #1807 (comment).
Want to back this issue? Place a bounty on it! We accept bounties via Bountysource.
The text was updated successfully, but these errors were encountered: