Database selection during authentication

Robert Ginsburg

We have an application that uses the SkyAPI. During a recent customer configuration , it turns out they they have two databases. We need to know how to select the correct database for generating the authentication token for use with the api. The UI of course at FE and RE lets you select a database. 


Any help is appreciated

Steven Cinquegrana

Hi Robert,


If you mean selecting between an FE and RE database, as opposed to, say, two RE databases, then, if they are in the same "environment" then the you should be able to utilize the same authentication (token set).


Authorization used to be by "tenant", meaning API group, such as FE APIs, RE APIs, the School API, etc. It was changed to environment last year (check the SKY API change logs for more details). Now, authorization is by environment and an environment can include any number of API groups and their APIs.


Our SKYLib.NET code library and SDK used to maintain multiple token sets for each tenant but now it does so for environments, though it's pretty unusual in our experience for a customer to actually have more than one environment. (We do, but we are a tech partner and we have to test all possibilities.)


I hope that helps.


Cheers,

Steve Cinquegrana | CEO and Principal Developer | Protégé Solutions

 

Robert Ginsburg

We are a tech partner as well (nice to meet you). It is multiple environments, this customer had a test data set running for awhile and then BB migrated their on premise data to a new environment. We have just about abandoned the idea of using the existing  account to authorize it and are going to setup a separate account that only has access to the new environment.


 

David Zeidman

We are also a tech partner and, apart from having a few environments ourselves, we have a number of clients that have multiple environments especially large organisations that are umbrella organisations or ones that have many chapters.


It is possible to specify the environment id when going through the authentication process. (Assuming that you have it). That way the user will only authenticate for that environment.

Robert Ginsburg

We finally arrived at a solution. Posted here for anyone else that runs into it. The situation is this, the Blackbaud FE customer had an initial staging environment created. We created an application and successfully connected to their FE instance via the SkyAPI. After a few months, a new environment was created for their production implementation.  Per the documentation here https://developer.blackbaud.com/skyapi/docs/authorization/auth-code-flow, we should have been able to drop the authentication and re-authenticate the same user and they would be presented with an environment selection in step 2 on the diagram. This did not happen, the only environment we could connect to was the original one. We tried dropping the user, removing the application from the tenant and re-adding it, and creating a new user. None of that worked, the only environment we could connect to was the original one. What did work, was deleting the application from both FE instances and then deleting the application from our developer portal. Creating a new application and adding it. At that point we could connect to the new environment and SkyAPI access was restored. Its not ideal as some of our applications are shared. I am thinking I will separate them so that we can recreate them if this situation reoccurs.


 

Steven Cinquegrana

Sounds like a back-end table not being updated when the enviro grouping changes. Nice one.

 

David Z: It is possible to specify the environment id when going through the authentication process.

Do you mean initial auth? Are you manipulating the web formlet submission in code?


It would be good to be able to specify the enviro purely in the auth flow but if you have to manually provide cred.s anyway, then selecting an enviro isn't a big imposition. The complication comes from selecting the wrong enviro and having your calls fail, having to request that the user select a different enviro, etc. Interested in your comments in any case.


Steve

 

Robert Ginsburg

we are not manipulating the user part of the dialog. According to the documents you can pass the environment_id as a parameter, but none of that worked until the application was dropped.  For us, this is part of the on boarding process so the user is a fairly skilled system operator, so its not difficult to get them to select the right environment. But it does have to actually recognize access. As you note, its probably a table not getting updated on the back end. For now its more an irritation then a blocker. 

 

 

Steven Cinquegrana

I just revisited the authorization tutorial pages and see the environment_id hint parameter you mention.


I sure don't recall seeing that when we developed our authorization code a year or so back, so possibly it's new, unless somehow I missed it, which I can't quite believe. (I sure wish these doco pages had change log details, or at least a Last Updated stamp.)


I haven't tried it yet but I don't think using the environment_id argument precludes the user having to select an environment, even though it says that it limits the available environments to the one supplied. Is that right? If so, I don't see why the selection of an environment would be necessary if there's only one (or none) available.