It's easy to create or rename a contact flow in Amazon Connect, but how do you delete one? The documentation doesn't mention anything about it and a Google search has come up empty.
Currently, in Amazon Connect, there is no way to delete or, for that matter, disable a contact flow.
From the Administrator Guide for Amazon Connect:
You can't delete a contact flow. To get obsolete contact flows out of your way, we recommend appending zzTrash_ to their name. This will also make them easy to find should you want to reuse them in the future.
AWS CLI now supports contact flow deletion.
From the Documentation:
delete-contact-flow
--instance-id <value>
--contact-flow-id <value>
[--cli-input-json | --cli-input-yaml]
[--generate-cli-skeleton <value>]
Edit:
Alternatively you can use the DeleteContactFlow API.
Related
I'm attempting to use Outh authentication for my PHP request to Salesforce but I can't get my ClientID and SecretID for my app.
I normally have an option to View these values but for some reason I'm unable to view them with an administrator login.
I created a new App and was able to get the credentials successfully, so I know it's not the account permissions preventing me from accessing this information.
Does anyone with experience of Salesforce have any experience with an inability to get these details?
Thanks!
Is it a normal app created in this org or managed connected app, coming from installed package? You can't see secrets of managed app.
For normal app they're hidden behind a button. For me clicking it takes me to email challenge (provide OTC or one-time code we've sent to your mailbox). Completing that I can access the page with key and secret I can copy-paste.
Your user might be misconfigured. Try to fish around with browser's source inspector, maybe the button's there but doesn't render?
<input id="appsetup:setupForm:details:oauthSettingsSection:manageConsumerKeySecretSection:manageConsumer" type="submit" name="appsetup:setupForm:details:oauthSettingsSection:manageConsumerKeySecretSection:manageConsumer" value="Manage Consumer Details" class="btn gsbutton">
Is your email valid in this org (maybe it's a fresh sandbox with ".invalid")? Do you use Multi Factor Authentication? Do you think you have "high assurance session" configured when accessing certain areas of setup? Can be in Setup -> Session Settings or in your Profile
thank you for writing back to me regarding the issue.
The issue I encountered was trying to get the API credentials for an existing app but I was able to create a new App which is posting the Leads successfully into the system.
So the answer to my problem was that the original app was misconfigured when it was created and I was able to create a new App to resolve the problem.
On AWS, I wish to create an application that allows a user to sign in via mobile, web or both.
I created a system using API Gateway, Lambdas and DynamoDB for the back end. I have sign in working for web using JavaScript but was having issues finding a Swift example for iOS of the same code (objective C only available). So I created a mobile hub application, imported my existing API and have a working iOS sign in.
The issue is that the iOS side uses the Mobile Hub so I now have 2 different User Pools so you can't sign up on web and log in on mobile (or vice versa).
I tried to change the settings in the iOS app to point to my web app Cognito User Pool settings and remove the secret but it errors as it can not be null or empty.
Why does the mobile hub require a client secret? The JavaScript documentation suggested was bad practice since code can be de-compiled and the secret extracted.
There doesn't seem to be any consistent documentation that explains, what I would guess, as the most common use case of a mobile and web app!
The other issue is that I can download my API client SDK for my API Gateway for use with web app and iOS app. But, the generated mobile hub app includes a REST based call? Am I going crazy here or does the official web approach not link to the official mobile approach?
So the key questions are:
Can or should I change the mobile apps to point at the original
Cognito?
if so should I remove the client secret?
can I effectively ignore the Mobile Hub after set up and use it purely for code generation? Assuming it was then working can I just use the generated client SDK for my API Gateway?
Is there a better way of setting up an iOS (later Android too) and web app?
I've spent considerable time and effort, and tried many approaches.
The "Mobile Hub" nicely sets up the user pool, identity pool, IAM roles etc.
The keys etc are mostly provided in the Info.plist file, although ( unwisely ) the developers of the user pool AWSSignInProvider made it have hardcoded keys in a configuration file.
SO:
If you don't intend to use the "Mobile Hub" console application for making changes to your mobile app configuration, then you won't need any more downloads. In that case, you don't have to worry about changes to Info.plist or the configuration file, and you can edit what you want.
It is unclear if you are going to use the mobile hub created identity pool and just want to insert your user pool, or if you want to change both pools. Obviously if you are using the same identity pool then some of the changes below will not be needed (they will be obvious because you will be changing them to be exactly the same).
So all you have to do is change the ID's to get everything hooked up correctly.
In general you need to fix all the downloaded keys and ID's in Info.plist and the configuration file, and then you need to update the server configuration. In more detail, here are the places you need to change it:
in the app:
update all the keys in Info.plist to be the keys you want. (specifically credentials provider and identity manager keys for google) But if you are using other mobile hub services, check the keys there too.
If you are using s3, and some of the other services the directory names/database names are also stored in the code... I leave it as an activity to find them.
in the file MySampleApp->AmazonAWS->AWSConfiguration.swift edit the keys provided by Mobile hub to match your user pool (do this while quietly swearing under your breath because they are not in Info.plist)
in the console:
put your app name in your user pool APP's list if it is not there, and record the user pool id, app id, and app secret.
click on federated identities and the identity pool created by mobile hub and update the authentication provider to use your cognito user pool id and app id.
if you are changing the identity pool too, then you will need to look at the IAM Roles for your auth and unauth users and specifically edit the policy that is named: .....yourapp....signin_MOBILEHUB_xxxxxxx, and change the identity pool id in that policy to be the one you want to use. Do this for both auth and unauth.
( you can change the id if you only use one pool, or add another to a list of id's like this if you will have multiple identity pools (for test...etc))
"Resource": [
"arn:aws:cognito-identity:*:*:identityPool/us-east-1:8s8df8f8-sd9fosd9f0sdf-999sd99fd",
"arn:aws:cognito-identity:*:*:identityPool/us-east-1:dfsf9099-sd9fosd9f0sdf-sd9f0sdf09f9s"
]
similarly, in the trust relationship associated with the roles, you need to fix the id's, (or handle multiple ID's if you want the role to serve multiple identity pools). Here is how to specify multiple id's there.
"Condition": {
"ForAllValues:StringLike": {
"cognito-identity.amazonaws.com:aud": [
"us-east-1:8s8df8f8-sd9fosd9f0sdf-999sd99fsdfdd",
"us-east-1:dfsf9099-sd9fosd9f0sdf-sd9f0sdf09f9s"
]
},
if you are using google too... you need to make sure that you have an identityProvider in the IAM configuration for google (mobile hub did that for you) and if you are using your own identity pool , in your federated identity pool authorization providers configuration you will need to select google open id provider (and put google in the authorized providers too (but I don't think this part is strictly needed))
facebook doesnt use OpenID Connect, it has a proprietary way of configuring into the authentication providers section, so enter those keys if needed in the identity pool authentication providers section.
And that should be enough to make it work.
And no you are not going crazy... the documentation does not match the current IOS SDK. Mobile hub uses the aws-mobilehub-helper-ios (github) which is built on TOP of the sdk, so the documentation does not apply to that either! Mobile Hub Helper has a nice design, so I recommend you use it, rather than the raw SDK.
(and lastly... and I am out of my depth here because I don't use API gateway, but my understanding was that the API Gateway is a way to get credentials to use AWS Services, and with the mobile hub app you will be using Cognito to get those credentials, so I am not sure you will need to bring the API Gateway into it...at all)
UPDATE
You may want to use no client secret for users of your javascript app, and use a IOS Mobile App on the same pool too. This can be done in two ways:
1) The better way is that you create two different client's in the user pool. For one you will generate a client secret, for the other you will UNCHECK the "generate client secret" box.
Then in your Federated Identity Pool you go to Authentication Providers, and click on Cognito, and specify TWO DIFFERENT PROVIDERS USING THE SAME USER POOL ID. (This is not really two different providers, but that is how the console makes you specify it). And you put the two different client ids in those providers.
Now both the IOS app and the Javascript app can access the pool and get authentication and credentials from the identityProvider and credentialsProvider.
2) A not so good way. The reason this way is worse is because I don't know the impact (if any) it has on the security of your mobile app. And at AWS there is nobody to ask the question to without buying a support contract. But the other way exists.
What you do is use the same client id in both apps, and you don't generate a client secret. To do this you put "nil" in the clientSecret. This works fine with some caveats.
First, the AWS Mobile Hub has a bug in it's AWSCognitoUserPoolsSignInProvider. That class requires that the clientSecret is non-null. But in the SDK, the only way to tell the SDK that you want no client secret is to pass nil! However there are workarounds.
(What I did was use the AWSCUPIdPSignInProvider.swift (that I wrote), which will work fine and I have a version that will take a nil for the secret. I did that because it was faster for me to test this out. you can find that signin provider on github if you want to use it)
But a better (more future proof) solution is probably to use the AWSCognitoUserPoolsSignInProvider that the mobile hub delivers, but change the code in AWSMobileClient to configure and register your own pool rather than letting AWSCognitoUserPoolsSignInProvider do it for you.
I haven't bothered to try this, (because we only have to do it because AWS has not gotten around to updating the github aws-mobilehub-helper-ios yet). But basically in AWSMobileClient instead of this code:
func setupUserPool() {
// register your user pool configuration
AWSCognitoUserPoolsSignInProvider.setupUserPoolWithId(AWSCognitoUserPoolId, cognitoIdentityUserPoolAppClientId: AWSCognitoUserPoolAppClientId, cognitoIdentityUserPoolAppClientSecret: AWSCognitoUserPoolClientSecret, region: AWSCognitoUserPoolRegion)
AWSSignInProviderFactory.sharedInstance().registerAWSSignInProvider(AWSCognitoUserPoolsSignInProvider.sharedInstance(), forKey:AWSCognitoUserPoolsSignInProviderKey)
}
you would have something like this code
func setupUserPool() {
// register your user pool configuration
// find the service configuration (we don't know if they set it as default)
let credentialProvider = AWSCognitoCredentialsProvider(regionType: .USEast1 (or your region), identityPoolId: "YourIdentityPoolId")
let configuration = AWSServiceConfiguration(region: .USWest2 (or your region), credentialsProvider: credentialProvider)
// configure and put your own user pool in the service configuration
let userPoolConfiguration = AWSCognitoIdentityUserPoolConfiguration(clientId: AWSCognitoUserPoolAppClientId, clientSecret: nil, poolId:AWSCognitoUserPoolId)
// now we register that pool with the service configuration using the key they use
AWSCognitoIdentityUserPool.register(with: configuration, userPoolConfiguration: userPoolConfiguration, forKey: AWSCognitoUserPoolsSignInProviderKey)
AWSSignInProviderFactory.sharedInstance().registerAWSSignInProvider(AWSCognitoUserPoolsSignInProvider.sharedInstance(), forKey:AWSCognitoUserPoolsSignInProviderKey)
}
But as I said above, solution 1, use two different clients and specify two different providers is preferred.
I have registered my application here.
I have given all permissions to my App in that panel as well.
I specifically need Groups.ReadWrite.All which requires an admin ? requirement I am not sure what this even means.
https://apps.dev.microsoft.com/#/application/
Okay App is registered and redirect url has been copied.
Now I take that redirect url copy it and paste it into the admin panel for apps. At this link at App Registrations
https://portal.azure.com/
I am not sure why I have to register in two different panels, one which gives me a redirect url for my native app and the other that leaves it blank.
Great So then I setup my iOS app to make a graph request. This scope
https://graph.microsoft.com/Calendars.ReadWrite
I need to readwrite groups so I add this permission
https://graph.microsoft.com/Group.ReadWrite.All
It fails to authenticate.
I have checked that I have added the permissions to my app, and I have at this app registration panel https://apps.dev.microsoft.com/#/application/
Then I try to add the same permissions in the
https://portal.azure.com/
it gives me
Unable to Complete Request Validation Error, then doesn't do anything.
I tried to add a non admin permission same error.
So what is going on here ... ?
So even though they told me use the Graph API from now on moving forward in the docs I tried to go back to their office 365 SDK for iOS, it also has problems as I cannot get the pods to work as per instructions.
I am 100% sure after this issue is resolved I will need permissions
Note: I work at as a consultant for a bank so if someone can tell me what the azure administrator at the bank has to do to get my permissions escalated to admin status that would be great....
Thanks
Those are 2 different registrations,
Per this documentation (https://graph.microsoft.io/en-us/docs/authorization/auth_overview), for personal accounts like live.com or outlook.com, use the Azure AD v2.0, and for the enterprise, use the Azure AD.
So, for your case, I believe you need the latter, the azure AD.
For this to happen, as you said, go https://portal.azure.com/ and add the app registration.
In order to do so, you would need to
select "Azure Active Directory" and go "App registrations".
Once you create an app, you would need to select "native" for the iOS, and then under app access, under "required permissions" add "Microsoft Graph" followed by selected permissions you would like.
To answer the note, you would need permissions to create an app at the portal, otherwise, you would need to ask for that permission or have the admin create an app for you.
Some samples are available at https://github.com/microsoftgraph/ios-objectivec-connect-sample and https://github.com/microsoftgraph/ios-swift-connect-sample for iOS samples.
Hope this helps!
Currently i am working on one of old project within that there is a client id and client secret. Now i want to update those with new client id and client secret using another Developer account. I followed each and every step from
https://developers.google.com/+/mobile/ios/getting-started
Google APIs Console - missing client secret
But i can see only client id. Where is the client secret ?
Here i can see only client id
Hey this is step by step process ,hope this helps you...
Step 1:
Goto Google Developer console and create new app
Step 2:Enable the google plus api
You can see the enable api in the Enable API's tab which is next to API Library ,which is visible in second image.
Step 3: Goto to credential in API & auth tab then select credentials option
select the type of authentication you require
then you will can see the configure consent screen configure the page with the information you wish to provide .
Step 4: Select the web Application option on top
and enter required url's
and finally click create button
once you do that ..you can see ...client id and client secret key...
When in iOS, the application type of the OAuth credential should be 'iOS'.
And then you should pass an empty string as the client secret in your code.
Keeping a secret (that is global to the entire application, not unique per user) in an app is NEVER EVER secure. See https://developer.okta.com/blog/2019/01/22/oauth-api-keys-arent-safe-in-mobile-apps This is an amazing article, please spend as much time as needed to understand it.
Because it can't be kept secure, using client secret in iOS is the old, outdated approach. Nowadays you want to use proof-key-code-exchange (PKCE). It's also explained in above link, but in short:
Generate a secret key in iOS, it is one time use for that one specific login
Only send the hash of the key to the login authority (Google). The original has not left the app yet
To get the tokens, you send: <AuthorizationCode,ORIGINAL secret> AuthorizationCode is also a one time use
Google can compare the "original secret" to the previously sent hash. It therefore knows you are not an attacker that has stolen the AuthorizationCode
Back to the question. Google let's you create different types of "Apps":
Web application: Has a client secret (It's on a backend server, not on a publicly accessible iOS app)
iOS app: Has "iOS URL scheme" instead. There are frameworks that use this URL scheme and do the steps I described above for you (including PKCE). Disclaimer: I'm not an iOS developer, but I'm 99% certain
I'm developing a Shopify App with Rails and have been using the query-string to detect which shop is accessing it. This seems vulnerable as users could alter the url to access someone else's settings.
Here's an example:
I click on the preferences link on my app and get redirect to http://example-app.com/preferences?shop=example.myshopify.com and get a page of settings related to the the store: example.myshopify.com
So what's to stop the user from changing the querystring to http://example-app.com/preferences?shop=notmystore.myshopify.com and logging in to a store that they don't own?
Should I use an authentication gem (https://www.ruby-toolbox.com/categories/rails_authentication) and make each user create a username and password to prevent spoofing attacks?
Interesting. There were live production Shopify App store Apps that did what you did Paul. When I found an App like that, I informed Shopify and they promptly knuckle wrapped the App developer. He learned his lesson pretty quick and was hopefully very embarrassed.
Shopify Partner accounts (free to get) provide you with a nice API token and a corresponding secret for your App that you can use to ensure when you get a merchant trying to access your App that the incoming shop
is actually a shop that installed your App and,
they have the right to use your App
You should really check that out.
I found the solution is to always retrieve the shop url from your session variables and not from the query string:
session[:shopify].url
also make sure this is at the top of each of your controllers to ensure the shopify session exists:
around_filter :shopify_session
as shown in this: https://github.com/Shopify/shopify_app/blob/f9aca7dfc9c29350f7f2c01bb72f77a54ece2b77/lib/generators/shopify_app/templates/app/controllers/home_controller.rb
This question may be too localized, but I'll try to give you a direction.
If you are using the query string as the only authentication method, then yes, you will get hacked/spoofed, etc. You need to do some form of authentication. - Shopify provides an API that can probably handle some/most of this for you.
https://github.com/shopify/shopify_api