1,397 karma · joined March 15, 2015
My posts and comments do not reflect the views of my employer.
I’m doing something somewhat similar, happy to exchange notes.
Splitting hairs but no, Oauth has nothing to do with authentication. An introductory article like this should address the distinction between authentication and authorization in the first section IMO.
My advice is to just always use the auth code grant with the PKCE extension. TLDR of that extension:
1) client generates a “secret key” that it sends with the authorization request. 2) server associates that key with the authorization code it returns to the authorized client 3) client must present that key again in order to exchange the authorization code for the access token.
Prevents the authorization code from being intercepted and abused.
This isn’t super surprising. Microsoft is desperate to get people to develop for the Windows platform and this obviously an incentive that developers will find attractive.
1st way: the way our Java devs thought Go was “supposed” to be written
2nd way: how Go should probably actually be written
By embracing the simplicity and Go’s opinionatedness the first time around, you’ll save yourself a lot of refactoring headache later.
TLDR: Before going down that route, you should make sure you really REALLY need them. Someone learning Go for the first time probably doesn't.
My biggest issues would be maintainability and, as you mentioned, using global maps. If your enum itself is not a string value, but you NEED a string representation, then it should just implement `Stringer`.
As far as maintainability:
- The naming convention used here is not consistent with how enums are named in Go. For a good example, see the HTTP package, specifically request methods and response status codes [1]. Really, it isn't even an appropriate naming convention for constant values in any language, with `UPPERCASE_UPPERCASE_minor_note`, it looks a bit silly and took longer for me to grok.
- What if I want to add a new enum variant? I seriously have to add it to three different places? If I start touching this map in places outside the original source file, things will get really ugly really fast.
- A bit nit-picky, but: why use an `int32` here?
This file, in my opinion, is over-engineered. Go code should be simple; many people learning Go for the first time hesitate to work that way, unfortunately.
Other common issues I see with people learning Go for the first time:
- Overuse of concurrency. People like to use the `go` statement wherever possible, and create overly-complex APIs with channels. Unless you have multiple events that need to be done in parallel, yet simultaneously needing to communicate between them, you should not use them in your package's public API. Let your package consumers choose when to make that call.
- Package structure, particularly in modules. People like `src` directories, but Go doesn't work that way. Your top priority as someone learning Go should be to dig through Go's standard library itself and see how it is organized.
I clicked one part (enums) and noticed a pretty glaring issue. The way you are doing enums is really _not_ conventional Go code and probably not something I would allow past a PR review. I’m saying this as someone who has built many production systems with Go and taught it to many devs coming from Java.
This guide is more in-line with how Go enums should be designed: https://blog.learngoprogramming.com/golang-const-type-enums-...
So, while I dig a little further, I think it’s fair to warn people to take this with a grain of salt. Use the language yourself and come to your own conclusions as OP did.
Beyond that, it is not a company problem IMO. One of the most common uses for custom domains is custom email addresses. If a website prevented me from using it, as you propose, I would be flabbergasted.
This article is written by someone who would personally profit from Google’s regulation. It’s an ad for his company disguised as virtue signaling.
Updates they have made to Safari, the App Store, and iOS generally have made millions of people more conscious of how applications they use every day consume and interact with their personal information. They've inspired other companies like Google to follow suit, and are having a huge impact on the targeted advertising industry.
Give credit where it is due.
To sum it up like that reduces both the enormity and complexity of the problem they are faced with. You say you get spammed with Trump ads; how many of those ads make claims that you could prove are irrevocably untrue? Politicians and people designing political ads are often experts at dancing in the "gray area" of truth.
I don't think it is fair to deny the fact that Facebook takes this problem very seriously, certainly beyond what would be expected from them as far as business obligations go. (I'm even saying this as someone building a product that would compete with them.)
People need to understand how to question, investigate, and challenge the sources of information they consume. If we can't do that, in the US or otherwise, then we are doomed.
Source: if you look at the articles of incorporation for my solely-owned and operated LLC, you'd find an identical purpose statement.
I imagine this will be an unpopular opinion here though.
Congratulations to Hasura on the launch!