I have an Azure Enterprise Application set up with Provisioning configured. It works fine. Now I want to completely delete the app.
Does it trigger any SCIM requests (e.g. DELETE /Groups, DELETE /Users) when the application is deleted? I could not find this use case in any docs. My guess and observation so far is it does not send any SCIM requests at all.
Your guess/observation is correct. Deleting the application should cause it to stop tracking user/group changes and stop sending any requests for them. Deleting the app will definitely NOT cause a mass deletion event.
Related
I created a code in Bot-frame composer and published in azure Bot. We have used SSO(single sign-on) in the azure bot. Created a manifest file and published in app studio in MS teams. I am getting the messages twice when I open the chat for the first time. What is the solution to resolve it.
For this issue there are two different approaches to solve.
Check whether you are using webhooks or not. If you are using webhooks, check whether you are having multiple webhooks with same ID, which could send double messages.
This can be some weird approach. Sometimes, microsoft authentication issue will raise and if you are still having issue after checking webhooks, kindly contact the customer support of Microsoft and ask them to reset the app secret key and re-deploy the application.
There is another reason behind this, because of the previous login issues stored in SDK can cause the duplicate messages.
https://github.com/microsoft/botframework-sdk/issues/4387
https://github.com/microsoft/botframework-sdk/issues/5798
Check the above links for reference.
I have a (not so small) project started with ReactJS and Firebase web SDK - and I would like to somehow manage (at least add & delete) users in my system.
I am totally aware, that there is an Admin SDK, but I wouldn't like to transition to that in the current phase of the development. I would like to go on with the web SDK.
I have seen this nice workaround regarding the user-addition - and I managed to create & insert users with that.
Now, I need a way to delete or suspend users (at least), if possible. (I don't need strictly to have the update option, I can live without that.)
Do you now any way / workaround to that - similar to the point 2. ? Any idea how to achieve that?
The mobile and web clients for Firebase Authentication are not capable of changing the status of an arbitrary user account. A user account only has permission to delete itself, not other accounts.
You will need to use the Admin SDK for that, from a backend or desktop system you control. Initialized with a service account, it will have privileged access to manage user accounts.
I am using a Custom Domain for a Google Application project. I have multiple projects and I use the same domain for each, although only one mapping is active at any time. Historically this has been as simple as Verifying the domain on the latest project and then Adding the domain. The domain has then automatically switched to the new project.
I have not used this approach for some months and when I tried it recently I got the messages
www.xxxxx.com is already mapped to a project.
xxxxx.com is already mapped to a project.
Research on StackOverflow suggests the use of the following command
gcloud beta app domain-mappings create xxxxx.com
This does look the right thing to do, unfortunately the response to the command is:
ERROR: (gcloud.beta.app.domain-mappings.create) App [aaaaaa] is the subject of a conflict: Domain 'xxxxx.com' is already mapped to another application. You must delete the existing domain mapping before you can re-map the domain, or you may specify 'DomainOverrideStrategy.OVERRIDE' on the request to force overwrite the existing mapping. Domain 'xxxxx.com' is currently mapped to an application on which you do not have permissions.
I do not want to use the delete approach since there will be a gap in service before the re-map. I would like to use the OVERRIDE option but I cannot work out how to add it to the gcloud command and I cannot locate any documentation.
Update 6Nov17.
In the absence of an answer I have used the delete approach and it worked as expected. The re-map was possible immediately after the mapping was deleted for the current app. Unfortunately for some users access to the web page was not possible, or error messages were returned, for a while. After about 10-15 minutes normal service was resumed. For my web site a gap of 10-15 minutes is manageable. This will not be true for many sites and I anticipate that Google Cloud will tidy up this procedure before it exits Beta.
If for some reason it is not possible to access the current app to delete the mapping then I guess deleting the app's subdomain information at the domain registrar will have the same effect, although it may be difficult to predict when the delete of the associated mapping will happen.
On the plus site the new automatic SSL provision worked flawlessly.
i want to deploy some classes from sandbox to production but while uploading i am getting dis following error.
"This organization isn't authorized to upload change sets to other organizations. For authorization, contact the deployment connections administrators on the organizations where you want to upload changes." guys what i should do? the same error is showing when deploying from production to sandbox also.i think i missed some steps. Can somebody suggest what steps should i take now?
The deployment isn't authorized on the production salesforce account, you'll need to log in there and enable it (or ask an admin in that org to do so)
From here: https://developer.salesforce.com/docs/atlas.en-us.dev_lifecycle.meta/dev_lifecycle/migrate_deployment_connection.htm
Before you can receive change sets from a sandbox or other organization, authorize a deployment connection in the organization that receives the changes.
Log into the organization that’ll receive inbound change sets.
Usually this is the production organization associated with your
sandbox.
From Setup, enter Deployment in the Quick Find box, then
select Deployment Settings.
Click Edit next to the organization from which you want to receive outbound change sets. Usually this is your sandbox.
Select Allow Inbound Changes and click Save.
You have to connect the organizations. In the org of the deployment, you can activate the connection from the setup.
I'd like to disable user access to my app so that I can perform a schema migration. I've looked into a few possibilities and found possible shortcomings:
Disable datastore writes - I'd rather just bring my whole application down so that people do not see any errors, etc. Also, I assume disabling writes will prevent me from performing the migration.
Disable the application - It's not clear to me that this would disable it only for my users, leaving me unable to perform the migration. I am also unsure of the disable/enable turnaround time.
Redirect my domain name to a temporary page - my app would still be accessible on appspot.com
Upload a new version of my app that doesn't respond to requests other than to direct to a "temporarily down" page.
Any suggestions?
Suggestion number 4 seems like probably the best way to do this. Some frameworks have a "maintenance mode" in which all incoming requests would be redirected to a page indicating the site is down due to maintenance. If your framework doesn't support such a mode, you can just upload a new version of your app (maybe call the version maintenance) and switch to that as your new default version. This version could be an empty app in which all incoming requests are turned to a "maintenance page" indicating the site is down for maintenance. Then manually go to the version of your app with the migration code and execute it (http://<version>.<appname>.appspot.com). Switch your apps default version to the new version with the new schema when you're done with the migration.
Explanation of your other ideas
Disabling writes would prevent even you from making writes on the application. I believe this was more meant for migrating from one app to another or other applications of "freezing" the datastore.
Disable the application would bring the app down entirely
Redirecting your domain would inflict a DNS lag on your migration, something that can take 48 hours to fully propagate each way (switching to the temporary page, then switching back to the new version)
As aforementioned, IMHO this would be the best way to do it.
Is it not possible to use both schema's, and use a new version of your app to migrate, which only uses the new schema. In this way you can always fall back to your old version.
By the way. Because the datastore is schema-less, It was always possible for me to change the "schema", without bringing the app down.
Go to GCP > App engine > Settings > Disable application.
You can sure enable your application ay any time.
If you disable this app, a few things will happen:
The app will stop serving
All data and state will be saved
Billing charges will still incur when applicable
Your task queues will continue to run. They can be paused in the Cloud Tasks UI