Torii provider name from adapter?

I have a Torii adapter that is posting my e.g. Facebook and Twitter authorization tokens back to my API to establish sessions. In the open() method of my adapter, I'd like to know the name of the provider to write some logic around how to handle the different types of providers. For example:

// app/torii-adapters/application.js
export default Ember.Object.extend({
  open(authorization) {
    if (this.provider.name === 'facebook-connect') {
      var provider = 'facebook';
      // Facebook specific logic
      var data = { ... };
    }
    else if (this.provider.name === 'twitter-oauth2') {
      var provider = 'twitter';
      // Twitter specific logic
      var data = { ... };
    }
    else {
      throw new Error(`Unable to handle unknown provider: ${this.provider.name}`);
    }

    return POST(`/api/auth/${provider}`, data);
  }
}

But, of course, this.provider.name is not correct. Is there a way to get the name of the provider used from inside an adapter method? Thanks in advance.

UPDATE: I think there are a couple ways to do it. The first way would be to set the provider name in localStorage (or sessionStorage) before calling open(), and then use that value in the above logic. For example:

localStorage.setItem('providerName', 'facebook-connect');
this.get('session').open('facebook-connect');

// later ...

const providerName = localStorage.getItem('providerName');
if (providerName === 'facebook-connect') {
  // ...
}

Another way is to create separate adapters for the different providers. There is code in Torii to look for e.g. app-name/torii-adapters/facebook-connect.js before falling back on app-name/torii-adapters/application.js. I'll put my provider-specific logic in separate files and that will do the trick. However, I have common logic for storing, fetching, and closing the session, so I'm not sure where to put that now.

UPDATE 2: Torii has trouble finding the different adapters under torii-adapters (e.g. facebook-connect.js, twitter-oauth2.js). I was attempting to create a parent class for all my adapters that would contain the common functionality. Back to the drawing board...

UPDATE 3: As @Brou points out, and as I learned talking to the Torii team, fetching and closing the session can be done—regardless of the provider—in a common application adapter (app-name/torii-adapters/application.js) file. If you need provider-specific session-opening logic, you can have multiple additional adapters (e.g. app-name/torii-adapters/facebook-oauth2.js) that may subclass the application adapter (or not).

Regarding the session lifecycle in Torii: https://github.com/Vestorly/torii/issues/219

Regarding the multiple adapters pattern: https://github.com/Vestorly/torii/issues/221

Regarding the new authenticatedRoute() DSL and auto-sesssion-fetching in Torii 0.6.0: https://github.com/Vestorly/torii/issues/222

UPDATE 4: I've written up my findings and solution on my personal web site. It encapsulates some of the ideas from my original post, from @brou, and other sources. Please let me know in the comments if you have any questions. Thank you.

I'm not an expert, but I've studied simple-auth and torii twice in the last weeks. First, I realized that I needed to level up on too many things at the same time, and ended up delaying my login feature. Today, I'm back on this work for a week.

My question is: What is your specific logic about?

I am also implementing provider-agnostic processing AND later common processing.

This is the process I start implementing:

1. User authentication.
   Basically, calling torii default providers to get that OAuth2 token.
2. User info retrieval.
   Getting canonical information from FB/GG/LI APIs, in order to create as few sessions as possible for a single user across different providers. This is thus API-agnotic.
   ➜ I'd then do: custom sub-providers calling this._super(), then doing this retrieval.
3. User session fetching or session updates via my API.
   Using the previous canonical user info. This should then be the same for any provider.
   ➜ I'd then do: a single (application.js) torii adapter.
4. User session persistence against page refresh.
   Theoretically, using simple-auth's session implementation is enough.

Maybe the only difference between our works is that I don't need any authorizer for the moment as my back-end is not yet secured (I still run local).

We can keep in touch about our respective progress: this is my week task, so don't hesitate!
I'm working with ember 1.13.

Hope it helped,
Enjoy coding! 8-)