Is it possible to move a payment profile from the authorize.net sandbox into a production CIM?
The sandbox and production environments are separate and it's not possible to move sensitive data from one system to the other.
Related
Assume that there is an application, SPA, that uses Google OAuth2.0 to access the Google Drive API.
Reading the docs, the application flow seems familiar enough on the client-side specially with Google's JavaScript library for authentication. However, I have stumbled upon a roadblock during application registration phase.
When creating the credentials for our client application, I am redirected to fill out the form at the OAuth Consent Screen first. There, among other things it demands us to declare whether the application is in Testing or In Production phase, so it can decide whether the app will be available to everyone or to Test Users only.
Assume I create a project for our application and set it on testing at first and then change it to production once I am ready to publish (with a new set of credentials as well).
My question is this. What if development continues on the application for new features while one instance of the app is in production? During development and testing I would need to restrict the application to my Test Users alone. Since the OAuth consent screen is project specific, not credential specific, will I require multiple projects on the console for every environment in which the application is running?
As in,
Project MyAppTesting will permanently remain in testing mode and will denote our development/testing branch.
Project MyAppProduction is always in production and denotes my production branch.
Similarly for the mobile client:
A MyMobileAppDev project having credentials configured with the debug keystore hash
A MyMobileAppProd project having credentials configured with the production keystore hash.
(both sets of credentials share the same package name).
Is this the idiomatic way? I failed to find any documentation on the matter. Please advise.
What #JohnHanley stated is the best way and the best practice when deploying application/s in GCP.
You can create multiple projects and create different Oauth for each of the projects. Check out this link on service accounts.
In addition to that, there are also some pros and cons when it comes to billing.
Pros:
Users consider having multiple billing accounts with respective projects assigned for each account to be able to see their billing details separately. In this way you can monitor the billing for each of the respective projects for each account.
Cons:
Attaching all the projects to one billing account, however, the billing reports will show all of the sum of the cost for all the projects, but you can still use the filter menu to be able to see the charges for each project.
We have two WFE servers and Application server for the SharePoint. User profile service is configured and we want use it. But User Profile Synchronization Service stays on starting state and after a while stops, then it makes the forefront identity manager services disabled too.
I just checked the farm user account access and also configure the service again and again to fix this issue.
The stuck on starting issue can be a real pain to deal with. Spencer Harbar wrote an article a few years ago that I, unfortunately, have to refer to from time to time. It's very comprehensive and there are several things that could cause the problem but it usually comes down to incorrect permissions on either a windows service, a SharePoint service, a DB, or issues in forefront. Bookmark this one... it will be your friend :)
http://www.harbar.net/articles/sp2010ups2.aspx
Make sure that the farm account is added to the local administrator group during starting and provisioning User Profile Sync Service service.
For more details check
User Profile Synchronization Service Stuck on Starting
User Profile Synchronization Service Starting then Stopped in SharePoint
Everything I searched for returns info about internal user SSO, not client facing websites.
I need an SSO implimentation that works with sitecore's asp.net membership api or has it's own sitecore security provider to enable users who log in to publicfacingwebsite1.com to be able to be logged in to publicfacingwebsite2.com and logging out of one will log out of the other. I would prefer sitecore's asp.net membership provider as that will probably have the least upgrade implications in the future.
The domains are different top level domains. The websites are separate sites on the same sitecore instance.
I also need the side ability to impersonate a user (log in as the user) from an admin user, but once I have the main implementation, I'm sure I can find a method for the impersonation.
Regards
I would use a third party framework for the SSO part. For instance IdentityServer3
Here is a good introduction on how to use it together with Sitecore
In regards to the membership provider and the profile data, if you are thinking upgradeability, I am not sure it will be so, if you use the native membership provider. Sitecore will most likely switch to ASP.Net Identity in the near future. The ASP.NET Identity is supported in IdentityServer3, so you might obtain a shared user profile by using IdentityServer for the profile as well. But this is all guessing the future.
If you want to use the membership provider and the standard Sitecore profile provider, I am sure you can customize the implicit flow to map the Identity to a Sitecore user.
I want to develop an application that will be able to dial in to corporate clients' Google Apps Domain to get user info and groups. Is there a sandbox available where I can do this? Otherwise it looks like I would have to provision a (say) 200 user account and this could be expensive. Or do corporate clients get a staging environment where I could test this work? Thanks.
There's no sandbox like this as far as I know. Partners and large customers will usually have test accounts for this type of work but I don't believe these are made available to the general public.
I'd recommend scaling down your tests to as few users as possible. Also, note that Groups do not cost anything to create. If you are going to have to do something like this yourself, make sure you select the flexplan to ensure you pay for only what you're actually using.
Another option would be to see about buying a Standard Google Apps account. Ensure all features you're working on are available for Standard accounts though. I don't know the market for them but I believe you can find accounts like this on Ebay for pretty cheap.
There is no sandbox, but
you can create a free 30-day-trial Account. (https://www.google.com/work/apps/business/).
if you have an existing Google Apps domain you can request a development domain via your reseller or Google Apps Partner.
My team is trying to develop a product for the google apps marketplace and I am having issues with the workflow in the new ADMIN SDK.
With the now deprecated Provisioning API we simply ask for a username and password from the account we are trying to manage.
With the ADMIN SDK it seems as though they would need to go enable the API, create a key and do a lot of manual work for this to happen. This really is a tough option for us as the technical level of our clients is not likely to be able to make this transition.
Is there something like the work flow for the provisioning API where they can enable management from a third party or a recommended workflow for a developer to build an application that can access any number of google apps accounts?
A use case for this is say I want to develop a different option for a console, I want to build a console web app and simply ask for credentials or easy setup routine and allow our users to manage their google apps account in a different way.
Thanks in advance,
Steve
The Admin SDK Directory and Reports APIs work correctly with 2-legged OAuth 1.0a which is what the Google Apps Marketplace currently supports and automates. You do need to turn the Admin SDK on under "Register for additional APIs" from your Vendor Profile page on the marketplace. Also, the Administrative APIs for the domain must be turned on. You'll get a generic error that the domain cannot use the APIs if it's off in which case you can direct the client to the exact CPanel page where they can turn it on.