The code didn't account for existence of SOCIAL_AUTH_SUBDOMAIN. So the
redirects would happen to endpoints on the SOCIAL_AUTH_SUBDOMAIN, which
is incorrect. The redirects should happen to the realm from which the
user came.
Strictly speaking, this sentence is talking about the IdP configuration,
while the backend is just GenericOpenIdConnectBackend, so the new
phrasing is more correct.
This fixes a batch of mypy errors of the following format:
'Item "None" of "Optional[Something]" has no attribute "abc"
Since we have already been recklessly using these attritbutes
in the tests, adding assertions beforehand is justified presuming
that they oughtn't to be None.
This fixes the following flow being broken:
* You start on
http://zulipdev.com:9991/accounts/go/?next=/upgrade%23sponsorship
(which we link to from e.g. /plans/)
* The form on that page has
`action=/accounts/go/?next=%2Fupgrade%23sponsorship`, i.e. it has correctly
URL-encoded the `next `value.
* You enter a realm name and hit submit.
* That redirects you to
`http://realm-26.zulipdev.com:9991/upgrade#sponsorship`, would is
correct if you are already logged in.
* However, if you're not logged in, `/upgrade` will serve a redirect
to the login page, landing you at
`http://realm-26.zulipdev.com:9991/devlogin/?next=/upgrade/#sponsorship`.
This page works. But in production, it would instead be:
`http://realm-26.zulipdev.com:9991/login/?next=/upgrade/#sponsorship`.
On this page, password login works but social login does not.
Note that the `next=` value is no longer URL-encoded, and thus is
parsed by the browser as `?next=/upgrade` + a hash of
`#sponsorship`.
* If you now login with Google auth, you find yourself on
`http://realm-26.zulipdev.com:9991/#sponsorship` (no /upgrade).
The root cause was that we have a bit of JavaScript in signup.js and
dev-login.js that is intended to handle this; but it was broken for
the social login case for unknown legacy reasons.
This bug appears to date from the original
b62bdde303 which introduced `next`
support for social backends in the first place.
This upgrades the Stripe API to the most recent version. Going through
the Git history, it looks like our current API version is at 2019-03-14.
The API version should be manually changed in Stripe dashboard at the same
time as the commit is deployed in production.
Backward incompatible changes that are relevant to our codebase between
(2019-03-14, 2020-08-27].
* 2020-08-27 - The `sources` property on Customers is no longer included by
default.
* 2020-03-02 - Nothing applicable
* 2019-12-03 - The `id` field of all invoice line items have changed and are
now prefixed
with `il_`. We only rely on this while we normalize the fixtures.
* 2019-11-05 - Nothing applicable
* 2019-10-17 - The `billing` attribute on invoices, subscriptions, and
subscription schedules is renamed to`collection_method`. The invoice
change is the one that is relevant to us.
* The customer object’s `account_balance` value has been renamed to
`balance`. Only used for the stubs at the moment.
* 2019-10-08 - Nothing applicable
* 2019-09-09 - Nothing applicable
* 2019-08-14 - Nothing applicable
* 2019-05-16 - Nothing applicable
https://stripe.com/docs/upgrades
Also normalize the following IDs in stripe fixtures
* price_[A-Za-z0-9]{24}
* prod_[A-Za-z0-9]{14}
* pi_[A-Za-z0-9]{24}
* il_[A-Za-z0-9]{24}
This commit adds more specific screenshots to our events and
research pages. The newer screenshots are properly sized such that
they fit well in a 400px width.
We also move a quote to improve the visual design.
The screenshots we have currently don't really fit into the width
available and the font looks too small. This commit adds newer
screenshots that have been scaled to fit a width of 400px such that
the font is readable with a small amount of content.
This is a prep commit to add the status emoji feature.
This function will add missing/extra parameters to the
emoji info object, that would need by the template to
render an emoji.
Co-authored-by: Yash Rathore <33805964+YashRE42@users.noreply.github.com>
This is a prep commit to add the status emoji feature.
We update the templates associated with the emoji
picker to add class `status_emoji` to `emoji` in the
popover. So we can later add the events when the user
selects the emoji.
We also update the functions in `emoji_picker.js` to
support opening emoji picker popover in the 'set_status_
overlay`.
We also increase the `z-index` of the `popover-flex`
class (This class is only added to popover-emoji content
if the view is mobile), so in the mobile view the emoji
popover doesn't go behind the '#set_user_status_modal'.
If a user doesn't have enable_drafts_synchronization set to True, then
don't let them access the drafts API. This will help protect us
against client bugs accidentally sending drafts to the server when the
feature is disabled.
Signed-off-by: Hemanth V. Alluri <hdrive1999@gmail.com>
This field will control whether or not a user wants to sync their
drafts between different clients. Defaults to enabled.
Signed-off-by: Hemanth V. Alluri <hdrive1999@gmail.com>
We allow a maximum value of one week to make sure there aren't a huge
number of rows in the table for any user (this could happen if stream
notifications are enabled).
This commit also fixes a small error in the user_settings test.
We only have one query which will change database state in this function,
and we already have a lock on the process itself, so there's no need for
a transaction.
This was added in ebb4eab0f9.