search

randomBrainstormer / MMM-GoogleCalendar

Google Calendar for MagicMirror²
MIT License
69 stars 46 forks source link

[Improvement] Added support for authorizing using the Phone #43

Open JPZV opened 1 year ago

JPZV commented 1 year ago

This is by using a generated QR Code on where the calendar should be.

This just add a new method, and authorize.js should be working fine when using Desktop App as before.

Sadly, the request URL is so big, so it generates a big QR Code, but it should be working just fine even on pretty small (relatively speaking) screens.

JPZV commented 1 year ago

Thanks!!! I'm glad that you liked the Pull Request.

I resolved both changes, but now I've found a new big issue, and it's that Google doesn't like private IPs neither .local top-level domains for Redirect URLs. http://localhost, which is what I used while developing this PR, works just fine for Google, but any other method like 192.168.0.20 or magicmirror.local will fail with "must use a domain that is a valid top private domain"

The only workaround is to set a false domain on /etc/host file from the local machine (not where Magic Mirror lives, but the "client" which scans the QR code), which is relative easy to do in Windows or Linux (and maybe MacOS?), but on many phones that's another thing. For that, you would need to use a DNS Server like Pi.hole, or use an own valid domain (and maybe open/forward ports on the router if the NAT Loopback is not enabled).

So, TL;DR: I don't know if you would want to proceed with this type of authorizing, because it becomes very hackish to do for the end-user (for me and maybe for many developers it's not that hard, I do have a domain and also a Pi.hole server, but I want to think about those random people who came here and are not that technician like us)

randomBrainstormer commented 1 year ago

Thanks!!! I'm glad that you liked the Pull Request.

I resolved both changes, but now I've found a new big issue, and it's that Google doesn't like private IPs neither .local top-level domains for Redirect URLs. http://localhost, which is what I used while developing this PR, works just fine for Google, but any other method like 192.168.0.20 or magicmirror.local will fail with "must use a domain that is a valid top private domain"

The only workaround is to set a false domain on /etc/host file from the local machine (not where Magic Mirror lives, but the "client" which scans the QR code), which is relative easy to do in Windows or Linux (and maybe MacOS?), but on many phones that's another thing. For that, you would need to use a DNS Server like Pi.hole, or use an own valid domain (and maybe open/forward ports on the router if the NAT Loopback is not enabled).

So, TL;DR: I don't know if you would want to proceed with this type of authorizing, because it becomes very hackish to do for the end-user (for me and maybe for many developers it's not that hard, I do have a domain and also a Pi.hole server, but I want to think about those random people who came here and are not that technician like us)

Thanks for diving into this. I get the tech hurdles we're facing. Asking users, especially those not super tech-savvy, to mess with the /etc/host file or dive into DNS setups can be a real headache. Sure, for pros and network gurus, this might be a walk in the park, but we've got to make things smooth for everyone else too.

Maybe we need to rethink the whole phone authorization thing or whip up a super clear step-by-step guide. Though, gotta admit, it could still be a puzzle for some. Got any ideas ? What if we let users toggle this feature on right from the plugin's settings? That way, we keep the flow smooth and just beef it up for folks wanting a bit more.

JPZV commented 1 year ago

Sorry for the delay! I have a crazy week right now!

Yeah! It's a total mess. Thinking about it, this will help to a handful of people actually, specially those who cannot have a keyboard/mouse attached to the mirror (on my case, I fried up the only USB port, and the board is sooooooooooooo slow so I cannot have any type of remote desktop on it), so it could be a good idea to leave it as an optional (disabled by default) setting.

Not sure if doing a guide would help though. I mean, we can link or re-use the documentation from pi.hole for example, but for me, a tech savvy, it took too much effort to make it work, even with the official documentation on hand, and many other guides on internet.

Anyway, I'll try to give it a little rework this weekend, but I'll use this same pull request, as it shouldn't change that much