rgardner / dancingtogether Goto Github PK

• split into separate js file
• add typescript compiler to toolchain
• convert to simple TS file with no semantic changes
• rewrite in TS

From testing with Nicole, we found that mute is likely good enough. Listeners can always disconnect by closing the browser window. The small mute icon on the tab is also not really discoverable and it's so small it's hard to use for many people.

Font Awesome

<i class="fas fa-volume-off"></i>
<i class="fas fa-volume-up"></i>

likely MIT, but first read through choosealicense.org

1. Users should be able to close their accounts and remove all info stored about them
2. Going to the login page when already logged in should redirect to the homepage
   • going to the join page when already logged in should also redirect
3. There should be a link to view your account when you're signed in (e.g. put the logout button behind a dropdown).

New account view in menu bar

• Signed in as {% account name %}
• Your profile
• Sign out

Spotify auth tokens are usually valid up to 1 hour. This means that if a user listens to the station long enough, the auth token will expire and Spotify will reject the request and currently, the only work-around is to refresh the page - which, is a minor annoyance :)

Instead, here's the proposed flow:

• continue to init station page with access token at start-up. This allows us to connect to Spotify as soon as it's ready, instead of relying on a websocket call down to the server first.
• when Spotify rejects the request because the access token has expired, it fires an authentication_error event. Today, only the music player is subscribed to this event to display a message to the user. Instead, that will be moved to the StationServer class, which will listen for this error and issue a "refresh_access_token" command to the server to get a fresh access token (must be done server-side).
• proposed test: plan is to create a mock spotify endpoint

Right now, no music starts when a listener joins a station. This is not expected :) When joining a station, the listener should catch up to the current state of the station. e.g. the music picks up at the current position.

https://webbkoll.dataskydd.net/en/results?url=http%3A%2F%2Fwww.dancingtogether.live%2F

Django channels removed the websocketbridge in a minor release, which has to be replaced with another reconnecting web socket implementation.

This causes an internal server error on station pages because the static file can't be found.

🚨 You need to enable Continuous Integration on Greenkeeper branches of this repository. 🚨

To enable Greenkeeper, you need to make sure that a commit status is reported on all branches. This is required by Greenkeeper because it uses your CI build statuses to figure out when to notify you about breaking changes.

Since we didn’t receive a CI status on the greenkeeper/initial branch, it’s possible that you don’t have CI set up yet. We recommend using Travis CI, but Greenkeeper will work with every other CI service as well.

If you have already set up a CI for this repository, you might need to check how it’s configured. Make sure it is set to run on all new branches. If you don’t want it to run on absolutely every branch, you can whitelist branches starting with greenkeeper/.

Once you have installed and configured CI on this repository correctly, you’ll need to re-trigger Greenkeeper’s initial pull request. To do this, please click the 'fix repo' button on account.greenkeeper.io.

This issue was generated by todo based on a TODO comment in 93e12ff. It's been assigned to @rgardner because they committed the code.

frontend_ci.yml

• lint
• test
• build_optimized

backend_ci.yml

• lint
• test

https://auth0.com/blog/how-to-configure-create-react-app/

Being back on the happy path will simplify maintenance.

e.g. users can only refresh their own access tokens, only admins can remove a station, only admins can add new listeners to their station, only DJs can update the playback state

• accounts
  • view profile
  • change password
  • delete an account
• main - index, about, contact are public
• radio
  • get stations
  • create a station
  • delete a station
• radio api
  • refresh a Spotify access token
  • get a station
  • update a station
  • get station listeners
  • add a listener
  • remove a listener

Scenario:

• client1 is at s1 (state 1)
• client2 is at s2 and sends message to server
• server is now at s2
• server broadcasts state update and updates track
• client1 has not updated track yet and sends s1
• server thinks client1 is stale and tries to update the track (again)

Plan

• version the states with etag
• client sends latest etag in player_state_change request
• server rejects stale etags
• when server broadcasts state update, it includes new etag
• etag = LMDT of station's playback state
• when client receives rejected state, it will wait X seconds to account for latency with Spotify, then try again. If it fails again, then do a resync (assume there was an error).

It was pretty loud when I first connected to a station. It would be nice to persist the setting so the sound isn't so jarring.

This is related to #9, as that allows changing the volume more than just mute/unmute.

I need to root cause this, it could be:

1. maybe the html is being cached with an old access token
2. the @spotify.fresh_access_token_required decorator isn't working as expected

This issue was generated by todo based on a TODO comment in 507567c when #52 was merged. cc @rgardner.

It's related to a javascript error in util.js, a bootstrap file. TypeError: t is undefined [Learn More]

Controls

• accept pending invites
• invite someone by email
• kick someone from station
• view names of connected listeners

e.g. ClientError('bad_spotify_response', 'Spotify servers are experiencing problems')

then surface this on the webpage. Maybe re-use the existing connection status message to say "Spotify is experiencing problems, the stream may not work as expected"

setVolume(0.0) then getVolume() returns null instead of 0.0. Client-side work-around is to treat null as 0.0

https://docs.djangoproject.com/en/2.0/howto/initial-data/

I think this was introduced in 9d5b222, as Django's CSRF protection requires the referrer header when HTTPS is used. Here's the Django dev post detailing what this is intended to protect against

The solution here is to turn off the no-referrer header, given its needed for CSRF protection over HTTPS.