internlm/SWE-Fixer-Train-110K huggingface dataset:
Repository: gratipay/gratipay.com

Issue:
connecting via twitter - cryptic screen
I have no idea what this screen means. what's the red thing ? what are the boxes on the right ?

What am I suppose to do ?

![screen shot 2013-05-22 at 11 24 33 pm](https://f.cloud.github.com/assets/250019/551281/22e3c548-c326-11e2-8c28-836d50f9058b.png)



Discussion:
oohhh I just figured it out. I had two accounts it seems !

I think the UI should mention it. "Reconnect" is quite vague. 

Something like "this twitter account is currently linked to BAZ, would you like to change it so its linked to FOO?"

I have to agree -- it is pretty cryptic how it looks now.  My guess would be that it's really merging the two accounts (since the receiving value is added as well)

I've never seen this screen; is this ticket no longer applicable to how Gittip is currently set up?

It is still applicable even though its rare to happen. One way to get it is:

Create a Gittip account using Twitter for example
Create another one for your project using Twitter
Connect a GitHub account to the first Gittip account
Login to the second account, the try to connect the same GitHub account to the second Gittip account.

So is this still an open issue or has it been resolved? Tarekziade said he figured it out, but it still seems to be an open ticket.


Resolving patch:
diff --git a/gittip/models/participant.py b/gittip/models/participant.py
--- a/gittip/models/participant.py
+++ b/gittip/models/participant.py
@@ -721,7 +721,7 @@ def take_over(self, account, have_confirmation=False):
         ever decide to join Gittip).
 
         In certain circumstances, we want to present the user with a
-        confirmation before proceeding to reconnect the account elsewhere to
+        confirmation before proceeding to transfer the account elsewhere to
         the new Gittip account; NeedConfirmation is the signal to request
         confirmation. If it was the last account elsewhere connected to the old
         Gittip account, then we absorb the old Gittip account into the new one,


Test patch:
Repository: gratipay/gratipay.com

Issue:
update payday self-checks to exclude manual exchanges
Reticketing from #2290.



Discussion:
I added `and recorder is null` to the four relevant queries. That fixed the first query in the function but now the third is choking on an old payday.

My hypothesis is that we repaired the paydays script in the past using a query that didn't exclude manually recorded exchanges. Now, don't we _want_ to include manually-recorded exchanges in the payday withdrawals figure? MassPay falls under this category (recorder is not null) and we want that reflected somehow.

That would require changes to payday.py and for now we really just need to fix the self-checks so we can get #2290 back on track.

Repaired in production with `update paydays set ach_volume =-1885.73 where id=74;`.


Resolving patch:
diff --git a/gittip/models/__init__.py b/gittip/models/__init__.py
--- a/gittip/models/__init__.py
+++ b/gittip/models/__init__.py
@@ -158,6 +158,7 @@ def _check_paydays_volumes(self):
                             where timestamp > ts_start
                             and timestamp < ts_end
                             and amount > 0
+                            and recorder is null
                         ) as ref
                     from paydays
                     order by id
@@ -174,6 +175,7 @@ def _check_paydays_volumes(self):
                             where timestamp > ts_start
                             and timestamp < ts_end
                             and amount > 0
+                            and recorder is null
                         ) as ref
                     from paydays
                     order by id
@@ -190,6 +192,7 @@ def _check_paydays_volumes(self):
                             where timestamp > ts_start
                             and timestamp < ts_end
                             and amount < 0
+                            and recorder is null
                         ) as ref
                     from paydays
                     order by id
@@ -206,6 +209,7 @@ def _check_paydays_volumes(self):
                             where timestamp > ts_start
                             and timestamp < ts_end
                             and amount < 0
+                            and recorder is null
                         ) as ref
                     from paydays
                     order by id


Test patch:
Repository: gratipay/gratipay.com

Issue:
session_expires is never checked
Reticked from https://github.com/gittip/www.gittip.com/pull/2041#discussion_r10321176.



Discussion:
★★★

It doesn't seem to be hard to implement. If I am right, I guess, I could do it.


Resolving patch:
diff --git a/gittip/models/participant.py b/gittip/models/participant.py
--- a/gittip/models/participant.py
+++ b/gittip/models/participant.py
@@ -92,7 +92,11 @@ def from_username(cls, username):
     def from_session_token(cls, token):
         """Return an existing participant based on session token.
         """
-        return cls._from_thing("session_token", token)
+        participant = cls._from_thing("session_token", token)
+        if participant and participant.session_expires < pytz.utc.localize(datetime.datetime.utcnow()):
+            participant = None
+
+        return participant
 
     @classmethod
     def from_api_key(cls, api_key):


Test patch:
diff --git a/tests/py/test_participant.py b/tests/py/test_participant.py
--- a/tests/py/test_participant.py
+++ b/tests/py/test_participant.py
@@ -643,3 +643,16 @@ def test_ru_returns_openstreetmap_url_for_stub_from_openstreetmap(self):
         stub = Participant.from_username(unclaimed.participant.username)
         actual = stub.resolve_unclaimed()
         assert actual == "/on/openstreetmap/alice/"
+
+
+    # participant session
+
+    def test_no_participant_from_expired_session(self):
+        self.participant.start_new_session()
+        token = self.participant.session_token
+
+        # Session has expired long time ago
+        self.participant.set_session_expires(0)
+        actual = Participant.from_session_token(token)
+
+        assert actual is None
Repository: gratipay/gratipay.com

Issue:
can't save any profile info
Reported by @chrisamaphone on [Twitter](https://twitter.com/chrisamaphone/status/476775868778704896).



Discussion:
I'm seeing 403s in the js console.


Resolving patch:
diff --git a/gittip/security/csrf.py b/gittip/security/csrf.py
--- a/gittip/security/csrf.py
+++ b/gittip/security/csrf.py
@@ -148,7 +148,7 @@ def outbound(request, response):
     """
     csrf_token = request.context.get('csrf_token')
     if csrf_token:
-        response.set_cookie('csrf_token', csrf_token, expires=CSRF_TIMEOUT)
+        response.set_cookie('csrf_token', csrf_token, expires=CSRF_TIMEOUT, httponly=False)
 
         # Content varies with the CSRF cookie, so set the Vary header.
         patch_vary_headers(response, ('Cookie',))


Test patch:
Repository: gratipay/gratipay.com

Issue:
fix regression in receiving amounts
Stripe is giving to Bundler now, but Bundler's "receiving" doesn't reflect this, due to a regression with #2352. [IRC](https://botbot.me/freenode/gittip/2014-06-12/?msg=16141806&page=1)

cc: @indirect @gdb



Discussion:

Resolving patch:
diff --git a/gittip/billing/__init__.py b/gittip/billing/__init__.py
--- a/gittip/billing/__init__.py
+++ b/gittip/billing/__init__.py
@@ -22,6 +22,29 @@
 from aspen.utils import typecheck
 
 
+def update_receiving_amounts(db, tipper, error):
+    """Update receiving amounts of participants tipped by given tipper.
+    """
+    from gittip.models.participant import Participant
+    tipper = Participant.from_username(tipper)
+    if tipper.is_suspicious or tipper.last_bill_result == error:
+        return
+    if error == '':
+        op = '+'
+    else:
+        op = '-'
+    db.run("""
+        UPDATE participants
+           SET receiving = (receiving {0} amount)
+          FROM ( SELECT DISTINCT ON (tippee) tippee, amount
+                   FROM tips
+                  WHERE tipper=%(tipper)s
+               ORDER BY tippee, mtime DESC
+               ) foo
+         WHERE tippee = username;
+    """.format(op), dict(tipper=tipper))
+
+
 def get_balanced_account(db, username, balanced_customer_href):
     """Find or create a balanced.Account.
     """
@@ -92,6 +115,8 @@ def associate(db, thing, username, balanced_customer_href, balanced_thing_uri):
     typecheck(error, unicode)
 
     db.run(SQL, (error, username))
+    if thing == "credit card":
+        update_receiving_amounts(db, username, error)
     return error
 
 
@@ -129,6 +154,8 @@ def clear(db, thing, username, balanced_customer_href):
 
     """ % ("bill" if thing == "credit card" else "ach")
     db.run(CLEAR, (username,))
+    if thing == "credit card":
+        update_receiving_amounts(db, username, None)
 
 
 def store_error(db, thing, username, msg):
@@ -142,6 +169,8 @@ def store_error(db, thing, username, msg):
 
     """ % ("bill" if thing == "credit card" else "ach")
     db.run(ERROR, (msg, username))
+    if thing == "credit card":
+        update_receiving_amounts(db, username, msg)
 
 
 class BalancedThing(object):


Test patch:
Repository: gratipay/gratipay.com

Issue:
support@gittip.com still linked several places
Should be support@gratipay.com, right? ;-)



Discussion:
support@gratipay.com hasn't been set up yet, if I recall correctly


Resolving patch:
diff --git a/gratipay/exceptions.py b/gratipay/exceptions.py
--- a/gratipay/exceptions.py
+++ b/gratipay/exceptions.py
@@ -30,7 +30,7 @@ def __str__(self):
         return self.msg
 
 class HasBigTips(ProblemChangingNumber):
-    msg = "You receive tips too large for an individual. Please contact support@gittip.com."
+    msg = "You receive tips too large for an individual. Please contact support@gratipay.com."
 
 
 class TooGreedy(Exception): pass


Test patch:
Repository: gratipay/gratipay.com

Issue:
broken facebook link when no user_name
If all we have is a user_id, we construct the URL improperly. In that case we need:

`http://facebook.com/profile.php?id=$ID`

But we have:

`http://facebook.com/None`

broken facebook link when no user_name
If all we have is a user_id, we construct the URL improperly. In that case we need:

`http://facebook.com/profile.php?id=$ID`

But we have:

`http://facebook.com/None`



Discussion:

Resolving patch:
diff --git a/gratipay/elsewhere/facebook.py b/gratipay/elsewhere/facebook.py
--- a/gratipay/elsewhere/facebook.py
+++ b/gratipay/elsewhere/facebook.py
@@ -9,7 +9,7 @@ class Facebook(PlatformOAuth2):
     # Platform attributes
     name = 'facebook'
     display_name = 'Facebook'
-    account_url = 'https://www.facebook.com/{user_name}'
+    account_url = 'https://www.facebook.com/profile.php?id={user_id}'
 
     # Auth attributes
     auth_url = 'https://www.facebook.com/dialog/oauth'


Test patch:
Repository: gratipay/gratipay.com

Issue:
Periodic tasks are run by each web process
**Original issue title:** "homepage is over-updated"

This is a regression from #2384. We're running four worker processes and we have an updater thread in each.

![screen shot 2014-07-09 at 10 08 52 am](https://cloud.githubusercontent.com/assets/134455/3525401/99332388-0772-11e4-86ea-9905b883b771.png)

<bountysource-plugin>

---

Want to back this issue? **[Place a bounty on it!](https://www.bountysource.com/issues/3039867-homepage-is-over-updated?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github).
</bountysource-plugin>



Discussion:
Workaround for now is to drop to one worker.

[IRC](https://botbot.me/freenode/gittip/2014-07-09/?msg=17694262&page=1)


Resolving patch:
diff --git a/configure-aspen.py b/configure-aspen.py
--- a/configure-aspen.py
+++ b/configure-aspen.py
@@ -1,8 +1,6 @@
 from __future__ import division
 
 from decimal import Decimal as D
-import os
-import sys
 import threading
 import time
 import traceback
@@ -75,17 +73,27 @@ def _set_cookie(response, *args, **kw):
 if exc:
     tell_sentry(exc)
 
-# The homepage wants expensive queries. Let's periodically select into an
-# intermediate table.
 
-def cron(period, func):
+# Periodic jobs
+# =============
+
+conn = website.db.get_connection().__enter__()
+
+def cron(period, func, exclusive=False):
     def f():
         if period <= 0:
             return
         sleep = time.sleep
+        if exclusive:
+            cursor = conn.cursor()
+            try_lock = lambda: cursor.one("SELECT pg_try_advisory_lock(0)")
+        has_lock = False
         while 1:
             try:
-                func()
+                if exclusive and not has_lock:
+                    has_lock = try_lock()
+                if not exclusive or has_lock:
+                    func()
             except Exception, e:
                 tell_sentry(e)
                 log_dammit(traceback.format_exc().strip())
@@ -95,7 +103,7 @@ def f():
     t.start()
 
 cron(env.update_global_stats_every, lambda: utils.update_global_stats(website))
-cron(env.check_db_every, website.db.self_check)
+cron(env.check_db_every, website.db.self_check, True)
 
 
 # Website Algorithm


Test patch:
Repository: gratipay/gratipay.com

Issue:
CORS headers for JSON endpoints have the wrong origin
Reproduction steps:
`curl -I https://gratipay.com/rummik/public.json | grep Access-Control-Allow-Origin`

Expected:
`Access-Control-Allow-Origin: *`

Actual:
`Access-Control-Allow-Origin: https://gratipay.com`

It looks like [gratipay/utils/cache_static.py#L69](https://github.com/gratipay/gratipay.com/blob/1853f335b9f03153ddaab12b9baba1ac4e582de9/gratipay/utils/cache_static.py#L69) is to blame, since our JSON endpoints specify the correct origin.



Discussion:

Resolving patch:
diff --git a/gratipay/utils/cache_static.py b/gratipay/utils/cache_static.py
--- a/gratipay/utils/cache_static.py
+++ b/gratipay/utils/cache_static.py
@@ -66,7 +66,6 @@ def add_caching_to_response(website, response, request=None, etag=None):
         return
 
     # https://developers.google.com/speed/docs/best-practices/caching
-    response.headers['Access-Control-Allow-Origin'] = 'https://gratipay.com'
     response.headers['Vary'] = 'accept-encoding'
     response.headers['Etag'] = etag
 
diff --git a/gratipay/wireup.py b/gratipay/wireup.py
--- a/gratipay/wireup.py
+++ b/gratipay/wireup.py
@@ -251,6 +251,14 @@ def compile_assets(website):
         os.rename(tmpfpath, filepath)
 
 
+def clean_assets(website):
+    for spt in find_files(website.www_root+'/assets/', '*.spt'):
+        try:
+            os.unlink(spt[:-4])
+        except:
+            pass
+
+
 def load_i18n(website):
     # Load the locales
     key = lambda t: strip_accents(t[1])
@@ -311,6 +319,7 @@ def asset(path):
         compile_assets(website)
     else:
         website.asset = lambda path: env.gratipay_asset_url+path
+        clean_assets(website)
 
     website.google_analytics_id = env.google_analytics_id
     website.optimizely_id = env.optimizely_id


Test patch:
diff --git a/gratipay/testing/__init__.py b/gratipay/testing/__init__.py
--- a/gratipay/testing/__init__.py
+++ b/gratipay/testing/__init__.py
@@ -4,7 +4,7 @@
 
 import itertools
 import unittest
-from os.path import join, dirname, realpath
+from os.path import dirname, join, realpath
 
 from aspen import resources
 from aspen.utils import utcnow
diff --git a/tests/py/test_public_json.py b/tests/py/test_public_json.py
--- a/tests/py/test_public_json.py
+++ b/tests/py/test_public_json.py
@@ -142,6 +142,12 @@ def test_authenticated_user_gets_self_for_self(self):
         assert data['receiving'] == '3.00'
         assert data['my_tip'] == 'self'
 
+    def test_access_control_allow_origin_header_is_asterisk(self):
+        self.make_participant('alice', last_bill_result='')
+        response = self.client.GET('/alice/public.json')
+
+        assert response.headers['Access-Control-Allow-Origin'] == '*'
+
     def test_jsonp_works(self):
         alice = self.make_participant('alice', last_bill_result='')
         bob = self.make_participant('bob')
diff --git a/tests/test.env b/tests/test.env
--- a/tests/test.env
+++ b/tests/test.env
@@ -3,3 +3,4 @@ CANONICAL_HOST=
 UPDATE_HOMEPAGE_EVERY=0
 CHECK_DB_EVERY=0
 RAISE_CARD_EXPIRATION=yes
+GRATIPAY_CACHE_STATIC=yes
Repository: gratipay/gratipay.com

Issue:
Minor text injection vulnerability
See https://gratipay.com/on/twitter/who%20you%20say%20you%20are...%20Visit%20gratipay.evilsite.com%20to%20verify%20your%20account%20and%20send%20me%20money.%20Maybe%20you%20don%27t%20have%20twitter/failure.html?action

Pretty minor I admit but could potentially be exploited with encoding. We should validate twitter/github/facebook usernames.



Discussion:
So, how to exploit that? Can you inject JavaScript or links there?

No, it's pretty minor. https://www.owasp.org/index.php/Content_Spoofing#Text_Injection

So the fix is to validate the elsewhere username on the failure page?

Yup :).
I can understand if that's quite a lot of work for such a simple problem.
I just noticed that there wasn't any verification going on.

[IRC](https://botbot.me/freenode/gratipay/2014-12-02/?msg=26665460&page=1)

Twitter handles are max 15 characters.

https://support.twitter.com/articles/14609-changing-your-username

Facebook is 50, according to a StackOverflow question answer. 

Limiting by size isn't probably the right way to go, though. We do know that they have to work in URLs, so one check could bounce if the input contains characters invalid in URLs. 

In practice, I think all the elsewhere sites handles are Latin characters without diacritics.

It would still be better to check validity with the platform in question.


Resolving patch:
diff --git a/gratipay/elsewhere/__init__.py b/gratipay/elsewhere/__init__.py
--- a/gratipay/elsewhere/__init__.py
+++ b/gratipay/elsewhere/__init__.py
@@ -114,7 +114,14 @@ def api_get(self, path, sess=None, **kw):
             sess = self.get_auth_session()
         response = sess.get(self.api_url+path, **kw)
 
-        # Check status
+        self.check_api_response_status(response)
+        self.check_ratelimit_headers(response)
+
+        return response
+
+    def check_api_response_status(self, response):
+        """Pass through any 404, convert any other non-200 into a 500.
+        """
         status = response.status_code
         if status == 404:
             raise Response(404, response.text)
@@ -123,7 +130,9 @@ def api_get(self, path, sess=None, **kw):
                , level=logging.ERROR)
             raise Response(500, '{} lookup failed with {}'.format(self.name, status))
 
-        # Check ratelimit headers
+    def check_ratelimit_headers(self, response):
+        """Emit log messages if we're running out of ratelimit.
+        """
         prefix = getattr(self, 'ratelimit_headers_prefix', None)
         if prefix:
             limit = response.headers[prefix+'limit']
@@ -149,8 +158,6 @@ def api_get(self, path, sess=None, **kw):
                         log_lvl = logging.CRITICAL
                     log(log_msg, log_lvl)
 
-        return response
-
     def extract_user_info(self, info):
         """
         Given a user_info object of variable type (depending on the platform),


Test patch:
Repository: gratipay/gratipay.com

Issue:
Twitter asks for authorization even though I've already authorized Gittip
As of #1369 Twitter is now asking me to authorize Giitip even though I've already done so.

![screen shot 2014-02-26 at 4 45 45 pm](https://f.cloud.github.com/assets/688886/2276800/fac5f68c-9f37-11e3-9dcc-5c77d35c6aa5.png)

<bountysource-plugin>

---

Want to back this issue? **[Place a bounty on it!](https://www.bountysource.com/issues/1428788-twitter-asks-for-authorization-even-though-i-ve-already-authorized-gittip?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github).
</bountysource-plugin>

Twitter asks for authorization even though I've already authorized Gittip
As of #1369 Twitter is now asking me to authorize Giitip even though I've already done so.

![screen shot 2014-02-26 at 4 45 45 pm](https://f.cloud.github.com/assets/688886/2276800/fac5f68c-9f37-11e3-9dcc-5c77d35c6aa5.png)

<bountysource-plugin>

---

Want to back this issue? **[Place a bounty on it!](https://www.bountysource.com/issues/1428788-twitter-asks-for-authorization-even-though-i-ve-already-authorized-gittip?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github)** We accept bounties via [Bountysource](https://www.bountysource.com/?utm_campaign=plugin&utm_content=tracker%2F85909&utm_medium=issues&utm_source=github).
</bountysource-plugin>



Discussion:
This is annoying but not critical. Demoting to ★★☆.

+1 https://gratipay.freshdesk.com/helpdesk/tickets/1048

This is annoying but not critical. Demoting to ★★☆.

+1 https://gratipay.freshdesk.com/helpdesk/tickets/1048


Resolving patch:
diff --git a/gratipay/elsewhere/twitter.py b/gratipay/elsewhere/twitter.py
--- a/gratipay/elsewhere/twitter.py
+++ b/gratipay/elsewhere/twitter.py
@@ -13,6 +13,7 @@ class Twitter(PlatformOAuth1):
 
     # Auth attributes
     auth_url = 'https://api.twitter.com'
+    authorize_path = '/oauth/authenticate'
 
     # API attributes
     api_format = 'json'


Test patch: