Skip to content
This repository has been archived by the owner on Jan 17, 2023. It is now read-only.

Sitehelper login #2413

Merged
merged 4 commits into from Mar 20, 2017
Merged

Sitehelper login #2413

merged 4 commits into from Mar 20, 2017

Conversation

ianb
Copy link
Contributor

@ianb ianb commented Mar 17, 2017

This has a couple cleanup commits that can be looked at separately from the main commit

Testing this is not terribly easy. You have to start run-addon and create a shot, then save the URL of that shot (not as a bookmark). Then shut the browser, start it up again, and try to visit the shot page. It should briefly appear unauthenticated, and then when the add-on auth fires it will change the page to be authenticated and you should be the owner. In theory if you delete cookies and revisit a page it will also re-authenticate.

This doesn't handle My Shots, I'm making a followup for that.

This improves the logging for synchronous errors by adding the stack, and adds equivalent logging to async promise errors
Change auth.login() to return the login success
Change auth.login() to have options for asking about ownership information, and suppressing register-on-failed-login
Change server to do an ownership check on a shot on successful login
Add wantsauth script that is used to eagerly talk to the addon and try to initiate login
Change shot/controller to use wantsauth
Copy link
Member

@jaredhirsch jaredhirsch left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@ianb I tried running through your STR in the description, but it seems that the shot I created is public by default, so the shot loads without a 404 step in any browser.

That said, I do see the login step in the network traffic:

screen shot 2017-03-20 at 12 43 35 pm

I also see a login event in the console:

screen shot 2017-03-20 at 12 43 39 pm

Code looks good, going to land this now



function sendCustomEvent(name, detail) {
if (typeof detail == "object") {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I guess this is okay: it's not an accurate check for objecthood, but it's unlikely that null, an array, or some oddball object like Math would ever get passed in here.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The type coercion here is a little sloppy, but objects in particular (as opposed to strings and numbers and null) trigger permission problems when transferring them between the add-on and content. I forgot about null==object though, that's an annoying case, but at least undefined (as when the argument isn't given) will be left alone.

@jaredhirsch jaredhirsch merged commit aa9451d into master Mar 20, 2017
@jaredhirsch jaredhirsch deleted the sitehelper-login branch March 20, 2017 20:17
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants