Sometimes we programmers stuck at a very simple problem. Why? Because we think it is really tough one, hidden somewhere inside the library we use, or maybe bad import of NuGet, or even by some sinister x86-x64 mismatches, huh? After hours of reconfiguration, it turns out everything was OK. The library is working fine, references were perfect and there is no problem with processor architecture. Finally – it was our fault, bad usage of somebody else’s code or… missing semicolon. ( ͡° ͜ʖ ͡°)
My missing semicolon
Today I wanted to share my ‘missing semicolon’-like error I wasted some time for – maybe it will save somebody’s time someday. And I don’t mean this particular situation I landed in, but generally, the attitude of starting the pursuit of bug from our parts. Not from the third parties, configurations, Flying Spaghetti Monster or external library author.
Lastly, I told you about my trouble with publishing CodeMate to the cloud. My GitHub logging was working fine locally and was corrupted when published. There was some error I needed to get some help. Finally, it turned out it was lacking DB configuration in Azure. But that’s not what I’m here to write to you about. On my StackOverfow’s post I got a good spot from Paweł, that my application requests the full access to the GitHub profile:
I was amazed because I only requested user’s email – in read-only mode. What happened then?
My code was simply doing that:
Nevertheless, I was constantly getting the ‘full access’ screen when logging.
I started to read the documentation on GitHub how to use scopes. It claims that when you pass user:email to OAuth – then only user’s email is requested. In read-only mode. Everything should be OK then.
I also noticed that when you pass empty scope, it will give you all user information, in read-only mode. I gave it a try:
but it didn’t work too! However, it guided me in a good direction. I checked the constructor of type GitHubAuthenticationOptions in Owin.Security.Providers library I use and I found that: 🙂
User scope was added yet in the constructor! So it was always there! The only thing I needed to do now was to clear the Scope list and then add what I need:
And it worked 🙂
Was is difficult? No. It was fairly simple. I guess too simple. As programmers, we tend to start looking for the bug in complicated places at the beginning – because the simple ones should work. However, confirming correctness of the unsophisticated parts may save us some time… sometimes 🙂
And that’s the message I wanted to send to you today.
It’s a high time to do the scheduling. Which means calendar needs to get in the application – that is what I’ll be working on in following week or two (hopefully not longer than that 🙂 )
Thanks for reading!
2 thoughts on “Do you always blame your code first?”
I would only add that usually those kind of issues are because of not really intuitive API, which in this case was full access permissions as default settings.
However that’s a good point, it’s better to check what I did wrong rather to blame everyone else 🙂
Yeah, I found that a bit tricky 😉 Cheers!