If we have other pages that require login, we might want them to redirect to
the login form. But the root of the site should take you to /accounts/home --
but only after we launch the product.
(imported from commit b5d10e1c908f1ffe1ee68c2689691ca66c896786)
The get_profile API call now returns a client_id, which an API user
can pass to update_pointer and get_messages (note that clients still
need to pass a pointer argument to get pointer updates). This
client_id is currently the equivalent of the website's session key,
but the website might get client_ids in the future to distinguish
browser windows.
This commit differs from 88f6cf0033c849af88d1b99da3bdc2148dfbb6fe in
that it uses request.POST.get("foo") instead of request.POST["foo"].
For some reason the latter triggers CSRF errors.
(imported from commit b2a4a7322d16dbf241cd6eef146621c79d84cafc)
This reverts commit 88f6cf0033c849af88d1b99da3bdc2148dfbb6fe.
It seems to have broken API users.
(imported from commit 2f861ebc016076547092421f87dbcac00a65e2f6)
The get_profile API call now returns a client_id, which an API user
can pass to update_pointer and get_messages (note that clients still
need to pass a pointer argument to get pointer updates). This
client_id is currently the equivalent of the website's session key,
but the website might get client_ids in the future to distinguish
browser windows.
(imported from commit 88f6cf0033c849af88d1b99da3bdc2148dfbb6fe)
This is similar to the previous "reason_empty" variable, but captures
why we've returned from the call even when there are updates and all
the reasons if there are multiple. For now, it's useful for debugging.
(imported from commit fd8d9e859660e51b57178d066b184f831b71a0b6)
This new call only allows fetching of existing messages. The idea is
to remove this functionality from get_updates to simplify the backend
code.
(imported from commit 1345db2f1707e208e7c0bd08b7d444932c68b6a2)
It's the safer default to prevent introducing XSS holes. And in our current
code, we always provide this parameter.
(imported from commit 73897f5315ba54a5d3fa95dd19efb9d20c081a8a)
The previous code path was buggy. We now do separate pointer update
checking for the cases where get_updates returns immediately vs. when
it returns from a callback.
(imported from commit f236a80cd0b94bc097dbd17f113d7a9d27368025)
For now, the new function, format_delayed_updates_response, just
calls format_updates_response.
(imported from commit dd332125fe0d47cb3990373f74e85e64604f58a3)
This allows us to check whether the session that updated the pointer
is the same as a session that is doing a long poll to avoid sending
new pointer information when that information is coming from the same
session.
We still return from the long poll early, though, which is sub-optimal.
(imported from commit 7d4be0956f112eacefb7d198ea929957cd2b05e3)
The client may now optionally send its current pointer during
get_updates and the server will return the latest pointer if it
differs and was updated more recently by a different session.
(imported from commit e43b377d7dfb52f83cefb0b1003863d5407caf80)
Mobile clients need it.
We are going to need to sit down and think about how much power we
want to give our API users, though. For example, should they even get
to know about your absolute pointer value (maybe they should only be
able to make requests relative to your pointer), or be able to request
very old ranges of messages?
(imported from commit 1680655f0d9a670bc0da0ddb92fbbd5cf851d3dd)