Hack accounts-base for custom service schema

I’m trying to adapt accounts-base to peculiar SSO service were service demands that user logs in multiple times to grant access to API. I’m also trying to do this from within a package, so I wouldn’t mind wrapping latest acccounts-base and trying to make things like accounts-ui work with it (or other SSO packages).

This is what package.js of accounts-base says:

  // Though this "Accounts" symbol is the only official Package export for
  // the accounts-base package, modules that import accounts-base will
  // have access to anything added to the exports object of the main
  // module, including AccountsClient and AccountsServer (those symbols
  // just won't be automatically imported as "global" variables).
  api.export('Accounts');

I’m looking to modify accountsServer’s method. Yet AccountsServer is undefined and won’t be imported (since meteor packages don’t do it), even though I have api.use('accounts-base', ['client', 'server']); I don’t even suppose that overwriting it from import will in fact overwrite base method.

What? No takers, I basically need to overwrite a package method?

answer me plox very plox

bump … complete sentence

I’m not 100% sure what you’re looking for as I don’t fully understand your question, why do they need to log in multiple times?

Anyway, have you installed Service Configuration? You can set up pretty much any SSO with it: https://atmospherejs.com/meteor/service-configuration

It works directly with the accounts package so once it’s up and running you’re good to go.

Yest Service configuration only takes one account per SSO, and I need it to take several external service multiple times for api access (refresh keys/access keys). This means that I have to modify login method for SSO for this service.

I’m also not sure what you mean.
Can you refrase your question explaining “MY PROBLEM”, “WHAT I DID”, “THE OUTCOME I EXPECT” & “HOW I THINK I SHOULD DO IT” so it’s easier for us to understand what you’re trying to do?

I have to let user login multiple times merging his accounts for the same
service, which account package doesn’t support for singular service, that
is service schema has no arrays or anything to identify number of times
service was activated on account.

I made variation of accounts SSO method that would trigger for that service
and, saving and triggering original method for everything else (should I
ever need that).

I expect user to be able to perform multiple logins, but accounts method
can’t be reached from within packaged from which I tried to overwrite it.

Ideally I wouldn’t have to git the accounts package into package dir,
otherwise my SSO package is less so publishable.

The problem here really is more so about meteor package system, and less so
about the SSO.

The package mikael:accounts-merge lets you merge accounts. Doesn’t that solve all your problems?
You can have multiple ways to log in with meteor’s accounts system, but most likely the provider (password, facebook, twitter, meteor accounts server, …) already solves that for you.
With accounts-merge, you can let your user log in with any of your providers, and then let her merge the accounts. This way if you logged in with Facebook, you can then log in with Twitter, and use the same account.

No accounts-merge merges diverent accounts. I need to merge different
external SSO/accounts into the same service. so like {service1: [account1,
account2]}, which obviusly accounts-base doesn’t support.

Ah, gotcha.

That’s a very specific issue, so I don’t think meteor accounts can handle that. You’ll need to make your own accounts system, or modify each provider you use (accounts-facebook, accounts-twitter…) to make it add multiple fields for each account.
If memory serves me correctly, each account is stored as { providers: {password: ...data, facebook: ...data}}, so you might be able to patch it to store the data as { providers: {password: ...data, facebook-$userId: ...data }} where $userId is the ID provided by facebook, so the keys don’t collide.

No your memory is bad as is understanding of SSO. Perhaps I could make my own meteor in lieu of not using random SSO packages that you know of or the accounts system.