Authorizing with rest-more (actually, random thoughts)

Before talking about authorizing with rest-more, let's talk about
omniauth first. I appreciate the work of omniauth, but it didn't
work for me. To be short, it didn't work for me because it's
trying to be very generalized amongst all the parties, however
the reality is, they are different in cases.

Things are getting better I believe, as more parties are choosing
OAuth 2.0 and stabilizing the specification. But given the current
situation, they just implemented OAuth 2.0 differently. Moreover,
since they already did that, before everyone agree on the
specification, they are not going to make things the same and
break stuffs.

In this regard, OAuth 1.0c is much more stable, though it's not
good enough for today's use cases.

omniauth tries to mimic those difference, but only if we only need
the very basic stuff. If we need a very specific stuff, we'll
probably end up with skipping omniauth, or only using it for
retrieving the access token.

I didn't look into omniauth carefully, and things are changing
all the time. I don't know if this still applies, but that's
what I've observed in the past few years.

Honestly, I've tried to do something similar to omniauth,
which is the RailsUtilUtil in rest-more. Why UtilUtil?
Because it's an utility to build the utilities. As we always know,
there are very similar stuffs in authorization and retrieving
information from a 3rd party. So of course everyone tries to
generalize them and keeps the maintenance minimum.

However I would probably call it a failure because they are
still different. I paid so much and ended up with a very complicated
code base for minimizing the difference, and make customization
as easy as possible.

They actually worked, and worked well. But they were outdated now,
and the problem is, I am too lazy to update them, because the
effort to do so is too expensive for me. Benefit is too little.

If I ever just did it straightforwardly, it would be much simpler.
In this case, I could be ending up with a ton of copypasta, but
it's actually much easier to maintain them, because I won't be
touching everything if I only need to fix one of the parties.

Frankly speaking, omniauth might not have this issue because
that's not it is sacrificing. I was sacrificing simplicity,
but omniauth was sacrificing performance, and now I am
sacrificing generalization for simplicity.

If you're going to optimize the authorization flow, you must
build the flow tighten to the framework you're using. In my
case, which is Rails. So I built RailsUtilUtil, instead of
something on top of Rack. Building on Rack means you're going to
be paying redirecting multiple times unless you're calling
API instead of doing redirects.

I love Rack and all my stuffs except RailsUtilUtil are based on
Rack if they are web based, but Rack won't work well in Rails,
at least to my requirement.

I am quite satisfied to what I'd done, that is simply doing what
really needs. They might look long, and some of the codes look
very similar but different, but they are very simple and
very easy to be maintained.

I could understand this could be tough for some people though.
Because you'll need to understand what's underneath very clearly.
Look at those session handling. Some people don't even understand
how session works. They are not going to know how to build from
scratch.

I still think DRY somehow made people done things much more
complicated than it needs. Copy and edit may mean more works
initially, but you'll appreciate it when you start trying to
treat different parties differently. Only generalize things
if they are really the same.

devise could be the other example which I refuse to work with.
(though unfortunately we're using it and I am maintaining it)
We are not going to have the same user system and working flow,
and even if we're initially, it would become a burden to change to
something different lately. The same applies to some "cloud"
user system.

I still think "people are using it" and "they should have done it"
are very bad reasons to choose a tool. To me, they are merely
excuses to avoid thinking what we really want. Use the tools to
build what we want, not see what we could do with the tools.

--
Well, I guess I still don't get it.
Not sure if I would ever get it.
Different people just do things differently,
and since they do things differently,
of course they would see different results.
If we don't try everything, we won't see everything.
Well, we just can't do everything, and even if we did,
I guess we still can't see everything.
I am still wondering and see, and
do what I think it should be done.