Unable to log in on localhost

[simonv3]

Operating system

Linux Mint

Browser name and version

Firefox 98

Expected behavior

Able to log in

Actual behavior

When I log in to the dev environment, I get redirected to the live api,

https://login.resonate.is/authorize?client_id=bt17o998d3b2m300u470.api.resonate.is&response_type=code&redirect_uri=https%3A%2F%2Fbeta.stream.resonate.localhost%2Fapi%2Fv2%2Fuser%2Fconnect%2Fresonate%2Fcallback&scope=stream2own&state=f42f9e81c837c281b1d2ed1ae13fba52e6973f8e

That redirect_uri looks incorrect, but I can't figure out how to set that on the localhost.

I click on "Allow".

And then I get redirected to this:

https://beta.stream.resonate.localhost/api/v2/user/connect/resonate/callback?code=5976cc31-22e0-4385-ac91-260e5f45f0d0&state=bb083b11d5e6f242fe37f13bf9912f30ca143b37

I think I'm missing a setup step but I tried adding beta.stream.resonate.localhost to my hosts file:

And now I'm out of ideas.

[simonv3]

I'm trying one more thing, taking the step to generate a cert for beta.stream.resonate.localhost

So I try to install mkcert, running the command for beta.stream.resonate.localhost as specified in the README.md

But still no dice. There's a lot involved in getting this running 😓

[auggod]

Ideally, you should run your own resonatecoop/id and resonatecoop/user-api. The issue is that open sourcing the api behind the player is still a work in progress...

I have recently merged code to remove login form from the player. It was using the password grant from the id server. Now we're going to use the authorization code grant. This stuff is not yet live on stream.resonate.coop.

As a security measure, I have expired the authorization code you have just copy pasted on github. : )

[simonv3]

@auggod thanks.

I feel like ironing this out should be a priority. I'm willing to help with this but just need to actually figure out getting it running first. If this is in progress, should I just wait a month and come back then?

I got a bit further today, but it required a lot of tinkering with nginx, and it's still not actually working. I'm just going to document all of this in case it helps others.

Generally there seems to be some mix-up in the front-end variables. The documentation seems to list beta.resonate.localhost but the redirect (as shown above) seems to be sending to beta.stream.resonate.localhost - I'm not sure what the difference here is meant to be. Keeping that in mind I used beta.stream.resonate.localhost to replace all references to beta.resonate.localhost

I added this nginx file /etc/nginx/sites-available/beta.stream.resonate.localhost, it's a copy of the file in docs as detailed in the "mobile" section of the readme, with some changes (primarily the sever_name change mentioned above, but also the redirect to https://localhost:8080 should be http://localhost:8080 (note the HTTP not HTTPS):

# This is an example nginx conf file to setup a development server for beta.resonate.localhost
# Don't forget to add beta.resonate.localhost to your hosts file
#
server {
  listen 80;
  server_name beta.stream.resonate.localhost;

  return 301 https://$server_name$request_uri;
}

server {
  listen 443 ssl http2;
  server_name beta.stream.resonate.localhost;

  allow 127.0.0.1;
  deny all;
  
  ssl_certificate      /usr/local/etc/nginx/ssl/certs/resonate.localhost.crt;
  ssl_certificate_key  /usr/local/etc/nginx/ssl/private/resonate.localhost.key;

  # enable session resumption to improve https performance
  # http://vincent.bernat.im/en/blog/2011-ssl-session-reuse-rfc5077.html
  ssl_session_cache shared:SSL:50m;
  ssl_session_timeout 1d;
  ssl_session_tickets off;

  error_log /var/www/localhost/resonate/beta/log/error_log;

  server_name_in_redirect off;
  rewrite_log on;

  root /var/www/localhost/resonate/beta/root;

  #location = /sw.js {
  #  expires off;
  #  add_header 'Service-Worker-Allowed' '/';
  #  add_header Cache-Control no-store;
  #  access_log off;
  #}

  # During development we can comment this
  #location / {
  #  try_files $uri $uri/index.html /index.html =404;
  #}

  location / {
    add_header Service-Worker-Allowed /;    
    proxy_http_version 1.1;
    proxy_set_header Upgrade $http_upgrade;
    proxy_set_header Connection "upgrade";
    proxy_set_header Host $http_host;
    proxy_set_header X-Real-IP $remote_addr;
    proxy_set_header X-Forward-For $proxy_add_x_forwarded_for;
    proxy_set_header X-Forward-Proto https;
    proxy_set_header X-Nginx-Proxy true;
    proxy_temp_file_write_size 64k;
    proxy_connect_timeout 10080s;
    proxy_send_timeout 10080;
    proxy_read_timeout 10080;
    proxy_buffer_size 64k;
    proxy_buffers 16 32k;
    proxy_busy_buffers_size 64k;
    proxy_redirect off;
    proxy_request_buffering off;
    proxy_pass http://localhost:8080;
  }

  location /embed {
    add_header Service-Worker-Allowed /;
    alias /var/www/localhost/resonate/beta/root/embed;
    try_files $uri $uri/index.html /embed/index.html =404;
  }
}

I also generated the certs as with the mkcert and moved them to the position referenced in the beta.resonate.localhost nginx conf, and created a /var/www/localhost/resonate/beta folder.

And so now, when I click on "log in" I do get redirected back to the site I'm hosting with npm run dev but it's directing me to a "page not found". I'm guessing this is where the expectation is that I'm running resonatecoop/user-api, and that actually the beta.resonate.localhost` mentioned in the readme is correct, but that I'm still missing a middle step.

[peterklingelhofer]

Hey @simonv3, and welcome!

I was not able to get nginx working with the project, and it should not be necessary to log in during local development. However, be aware that if you refresh the page, you will be logged out (per #155).

@auggod has been delivering a lot of updates to our back-end and login API in the past few days. For a few days there, I too was being redirected to beta.stream.resonate.localhost, but now it seems to be functioning as normal. I just attempted logging in after updating my development branch from the latest upstream, and it's working just fine for me.

Let me know if you're still running into this problem, and I can help try to assist you in troubleshooting as best you can. I too, when I first started, tried to get nginx working with this project, but it's technically unnecessary (thankfully).

Did you recently make an account with Resonate? Or have you had an account that's existed for a while?

[simonv3]

@peterklingelhofer thanks!

Just to confirm you're able to get everything loaded when using the localhost:8080 URL in the browser? When I use that, and click on "log in" in the top right corner, I get redirected to beta.stream.resonate.localhost, for which I get an "Unable to connect" error from the browser (as in, the standard "website doesn't exist" browser error)

I have an account from a super long time ago. Does that affect this?

[peterklingelhofer]

@simonv3 you're absolutely right. As of this evening I am also getting redirected to https://beta.stream.resonate.localhost/api/v2/user/connect/resonate/callback?code=............................&state=.............................

Based on @auggod said above "Ideally, you should run your own resonatecoop/id and resonatecoop/user-api. The issue is that open sourcing the api behind the player is still a work in progress..." given recent changes to these two repos and the fact that the latest development branch on here is a bit of a staging ground (has not been merged into live yet I bet), it may not work as intended until development is merged into live (and/or the WordPress transition is complete).

I haven't run the id and user-api repos locally yet, but it seems that may be necessary while we're in this transition process away from WordPress.

[peterklingelhofer]

@simonv3 in the meantime, there are a few issues you could try to tackle without having to log in. I've just marked every issue that should be accessible without having to log in with the good first issue label.

[simonv3]

Thanks for validating 😅 @peterklingelhofer !

I've also noticed that because of it using production API, and it looks like production API allows localhost:8080 for CORS, it's possible to grab the client_id off of one of the requests on the production stream instance and pass it along locally to fetch data.

I'll try and take a look at an issue over the weekend!

[caprenter]

Hello
I'm also struggling to get this working.
I have an instance up and running, (following the first few paragraphs of the read me) but I can't see/fetch any data - images and tracks don't load.

I get a 404 if I go to http://localhost:8080/login

I can see that if I adapt a 'known' URI that stuff is getting blocked:
https://stream.resonate.coop/u/18562/playlist/2022-04-24-resonate-on-camp-radio
try:
http://localhost:8080/u/18562/playlist/2022-04-24-resonate-on-camp-radio

So Firefox developer tools says:

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://beta.stream.resonate.coop/api/v3/resolve/apiDocs?type=apiDoc&basePath=%2Fapi%2Fv3%2Fresolve. (Reason: CORS header ‘Access-Control-Allow-Origin’ missing). Status code: 302.

Cross-Origin Request Blocked: The Same Origin Policy disallows reading the remote resource at https://beta.stream.resonate.coop/api/v3/resolve/apiDocs?type=apiDoc&basePath=%2Fapi%2Fv3%2Fresolve. (Reason: CORS request did not succeed). Status code: (null).

12:56:37 🚨 stream2own TypeError: NetworkError when attempting to fetch resource.

Any pointers are appreciated. Thanks for your hard work!

[peterklingelhofer]

Hey @caprenter,

I believe the login issues are to be expected currently, while we transition to the new login. It's why the beam app uses a token to log in currently (check the Readme for directions as to how to get a token).

The other fetch issues seem to new to me though. Maybe until those are resolved you could assist with some of the issues for the beam app. Thanks for your interest and please don't hesitate to ask any further questions!

In the meantime, you could tackle some of the issues marked as good first issue on the beam app. Please don't hesitate to ask if you have further questions!

EDIT: It looks like this could be the possible fix.

[auggod]

@caprenter I see your sending a request to beta.stream.resonate.coop and not stream.resonate.coop. That should be the issue.

[simonv3]

Yeah, I think this is slightly different from the issue I reported.

If you update your .env file with this value you'll see everything loaded:

APP_DOMAIN=stream.resonate.coop

When I do that, I do see albums and everything, but when I click on "Log in" I still get redirected to the live stream.resonate.coop (as per the original issue).

[caprenter]

Thank you everyone - the environment variables are the answer to my issue. Sorry if that's taken this thread off topic.

In the README

stream/README.md

Line 80 in c921f02

cp beta/.env.example beta/.env

I wondered if just copying the example was enough. I'm not sure if I should have known to make the change in the .env file.

Does that need adding in to the README?

[simonv3]

It's probably worth just updating the .env.example file directly I think?