Manually-inserted SSO rows breaking logins

(Emma Lejeck) #1

Some of our users are getting “There is a problem with your account. Please contact the site’s administrator.”

I’m not surprised, honestly, because I generated rows with our existing external_id mappings (necessary since our previous forum integration apparently never synchronized emails, only usernames, yay!), but I could really use some help figuring out what part is causing an error, because, well, there’s nothing in any of the logs, whatsoever. Anyways, the following shows an example of two SSO rows, the top being a successful one, and the bottom being an autogenerated one.

   id   | user_id | external_id |                                                                                                                                             last_payload                                                                                                                                             |         created_at         |         updated_at         | external_username |     external_email    | external_name |                                      external_avatar_url
 110954 |    6800 | 5554        | nonce=1cc3f9b19f346d83ac3e2291270b717f&username=Nuck&   | 2016-05-16 08:22:49.848162 | 2016-05-18 04:12:21.498766 | Nuck              |  |               |
 102340 |      35 | 16          | nonce=94b757f6d1dfc78e0e0dafd04d8dcf4b&username=Anotheruser&                                                                                                                                                                                                            | 2013-09-17 19:34:37.005088 | 2016-02-27 22:46:24.416587 | Anotheruser       | |               |

I can’t imagine last_payload would cause any trouble, but everything else seems right. And last_payload should be just as good as the factory in the test suite, so I’m at a loss.

Looks like it’s not logging because of this great catch-and-release:

“Oh just put an @ in front of it, that’ll fix it” — PHP dev

I’ve been trying to pin down the source of the validation error by reading the source code and testing things in the rails console, but with this much indirection and I can’t even figure out which model it could be. Both the SingleSignOnRecord and the User pass .valid? so I’m stumped

(Erick Guan) #2

That exception only happens when save!

You would open verbose SSO setting to compare more records.

I spent 2 days on related code for importing new users avatar. You would find a cleaner refactored code in my pull request.

Hope those two stuffs can help.

(Robin Ward) #3

This is an unfair criticism.

As @fantasticfears pointed out you can enable verbose sso logging to debug your SSO issues. We run many sites here and found the logging of a validation error was not useful unless you were specifically debugging SSO.

Additionally, if you’re comfortable inserting rows manually into the database, I think you should be comfortable opening a console and debugging code that way? Or perhaps creating a plugin to add any logging we don’t provide?

(Emma Lejeck) #4

That’s understandable, except there’s no logging on this rescue, only on the one below it (which doesn’t, for some reason, follow the SSO verbosity). So it ends up being exactly the same as adding an @ sign in PHP, even if accidentally. It’s a reasonable accident, I’ve made it a million times, but it’s also rather frustrating.

Should I send a PR fixing the logging so that it doesn’t treat validation errors separately and everything is just under the SSO verbose setting? Or would it be better to just add separate verbosity-obeying logging to the validation error alone?

I’ve been using it, but both the SingleSignOnRecord and the User pass a valid? check, and I can’t find any other model that could be invoked here, so I ended up stumped.

Unless there’s something weird going on here, valid? should return true in any case that would trigger save! to raise that error. Yeah, just confirmed that both are passing validation.

(Erick Guan) #5

Yes, that’s true. But which point the valid? is true? user is save! for twice and sso_record is saved for once.

You are operated on Rails console. Sometimes a copy & paste of invisibles/wrong characters might dramatically different for debug purpose.

(Robin Ward) #6

Ah I see. I’d be okay changing things such that validation errors are logged if validation errors fail and if verbose_sso_logging is enabled. (It’s still not the same as @ which swallows all errors though – this is just one deliberate error we didn’t find useful.)

Also, if your console is returning valid? from the object, are you sure logging there will give you any useful information? As discussed, that block should not execute if the record is valid and you are receiving valid? in the console.

In the meantime, you could try adding a log to that method on your install via a plugin (or running off your own fork) and see what happens.

(Emma Lejeck) #7

Well, we’re getting that render text: message, but not seeing the log that we get from the generic rescue, so I’m assuming it’s gotta be the validation. I don’t see any other flow that it could be