Open maxthiel opened 5 years ago
Hi @maxthiel. Is the issue just the page being unreachable or is the authorization not completing successfully? In other words, are you able to see the album arts on the toast after the login/authorization?
The /auth_redirect.html
page is just a low effort confirmation page, so I can easily move that here on Github. Accessing it through the local server was the first thing that crossed my mind since I was already using it for the auth flow.
Hi,
I think the auth worked, as I'm now seeing the cover in the toast, and I don't get a request for auth any more. Not sure if it's because my :80 port might already be used by some other program, so you might have the possibility to use a custom port for the local server?
Thanks!
Yep, I could use a custom port, but not a random one unfortunately since it needs to be registered beforehand on the Spotify's dev page. I'm currently trying to re-design the auth flow to to be able to use a random port.
I'm still seeing this behavior. After the failure described above, everything works fine. But the credentials aren't saved, so each time I start Toastify again, Chrome is opened to authenticate my Spotify account.
@Goro2030 same here
Same behavior here. Toastify seems to work anyways, so maybe is not a critical page to display.
same issue here
I'm still seeing this behavior. After the failure described above, everything works fine. But the credentials aren't saved, so each time I start Toastify again, Chrome is opened to authenticate my Spotify account.
@Goro2030 I had the same problem but I think I've been able to solve it. I observed that the Spotify WebAPI indicator was red even after approving the authentication page and that there was no spotify-token.sec
file in %LocalAppData%\Toastify
. After unchecking the Read-only
attribute of the %LocalAppData%\Toastify
folder the spotify-token.sec
file is created successfully and the WebAPI indicator turns green. After this I don't get the auth request again, cover-art is displayed in the Toast and the Paused
indicator is no longer persistent as before.
Hope this can help.
EDIT: Running Toastify as administrator accomplishes the same thing. A cleaner solution I guess.
EDIT2: Read-only is reapplied on reboot. Running as administrator once isn't enough either as it seems Toastify modifies spotify-token.sec
each time it starts. Checking the Run this program as an administrator
checkbox under the Compatibility
tab of the .exe works permanently though.
Tried what you suggested, but I'm still getting:
This site can’t be reached
localhost refused to connect.
ERR_CONNECTION_REFUSED
Saludos, Mariano [image: cloudHQ] https://chrome.google.com/webstore/detail/free-email-tracker/nknojfclnachdkpdkjbbhbkgpnladhnj Powered by cloudHQ https://chrome.google.com/webstore/detail/free-email-tracker/nknojfclnachdkpdkjbbhbkgpnladhnj
On Fri, Sep 6, 2019 at 2:58 PM fragande notifications@github.com wrote:
I had the same problem but I think I've been able to solve it. I observed that the Spotify WebAPI indicator was red even after approving the authentication page and that there was no spotify-token.sec file in %LocalAppData%\Toastify. After unchecking the Read-only attribute of the %LocalAppData%\Toastify the spotify-token.sec file is created successfully and the WebAPI indicator turns green. After this I don't get the auth request again, cover-art is displayed in the Toast and the Paused indicator is no longer persistent as before.
Hope this can help.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aleab/toastify/issues/111?email_source=notifications&email_token=ACS7DGSZYLO3NW26G3V4GOTQIKR5TA5CNFSM4GYKGBD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6DYGDA#issuecomment-528974604, or mute the thread https://github.com/notifications/unsubscribe-auth/ACS7DGQJFXIB7XHNMBBQ3HDQIKR5TANCNFSM4GYKGBDQ .
I don't think that matters. I think that redirect is only supposed to be a local confirmation page, it doesn't actually do anything. The important thing is that the spotify-token.sec
is created (or updated). Unfortunately it seems like the token still expires after some time so the Toast stops working. It will however be refreshed next time you start Toastify without requiring a new authorization.
It is important seems to ... as I'm being asked for the Facebook authorization each time I start Toastify....
On Tue, Sep 10, 2019 at 7:36 PM fragande notifications@github.com wrote:
I don't think that matters. I think that redirect is only supposed to be a local confirmation page, it doesn't actually do anything. The important thing is that the 'spotify-token.sec' is created. Unfortunately it seems like the token still expires after some time to the Toast stops working. It will however be refreshed next time you start Toastify without requiring a new authorization.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/aleab/toastify/issues/111?email_source=notifications&email_token=ACS7DGWNS5N6HATZDZ7FLULQJAOQNA5CNFSM4GYKGBD2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD6MWOXY#issuecomment-530147167, or mute the thread https://github.com/notifications/unsubscribe-auth/ACS7DGQPWCGTV5IRPSZ44SDQJAOQNANCNFSM4GYKGBDQ .
EXPECTED BEHAVIOUR
After login through a browser window, you should be redirected to Toastify or Spotify without problem.
ACTUAL BEHAVIOUR
After authorising Toastify, you get redirected to an unreachable page at
http://localhost/auth_redirect.html
STEPS TO REPRODUCE THE BEHAVIOUR
http://localhost/auth_redirect.html
unreachable pageLOG FILE
Log: