Iam using cybersource for credit card payment.
Created username token for security data with the test account created
When Executing
self.response = self.client.service.runTransaction(**options)
Gets error
Server raised fault: '
Security Data : UsernameToken authentication failed.
'
Thanks in Advance
I got it.......
Just Generate transaction security key and give the generated key as password.
Able to connect successfully.
Steps to create key
Using a web browser, navigate to the CyberSource Enterprise Business Center (EBC) Test Environment login page
Log in using a username with Administrator credentials
Click Account Management from the menu bar on the left side of the screen
Click Transaction Security Keys In the expanded sub-menu,
Click the link, Security Keys for the Simple Order API on the Transaction Security Keys page
Click Generate Key
At this point you may see a pop-up dialog box asking if you want to block dynamic content on the page. Select No if this dialog box appears.
Click Generate Certificate Request when it appears (it may take a few seconds to load)
When the key generation script is done, a dialog box will appear which asks you to select a location on your computer where the new security key will be saved.
Save the key (the naming convention is <your merchant id>.p12)
Deploy the key to your system
Related
I'm at the step where you link the Google account where the NEST devices are authorized in these instructions, I build up the URL with the project ID from the device access console and my newly created OAuth 2.0 Client ID then visit the resulting URL (https://nestservices.google.com/partnerconnections/etc....).
It shows my two NEST devices, I slide them on, click next and consistently get:
You can’t sign in because sent an invalid request. You
can try again later, or contact the developer about this issue.
along with Error 400: redirect_uri_mismatch
The instructions do mention:
you may get a warning screen that states Google hasn't verified this app. If so, to continue, click the Advanced option and then click Go to Project Name (unsafe).
But there is no "Advanced option" on this screen.
I've verified that the Smart Device Management API is enabled and that the Smart Device management scopes have been added to the project,
Any ideas?
I'm setting up OIDC provider for Cognito User pool. The open id connect service I'm using is Paypal. At the step where paypal issues code and redirects to cognito's /oauth2/idpresponse endpoint after which cognito is supposed to exchange the code for access token, I'm receiving "Exception processing authorization code" error. As you can see the error message is not very discriptive.
I have no idea what I'm doing wrong. I did setup open id connect properly. Setup client settings in cognito and etc.
These are the endpoints I'm using for openid connect:
https://www.sandbox.paypal.com/signin/authorize
https://api.sandbox.paypal.com/v1/identity/openidconnect/tokenservice
https://api.sandbox.paypal.com/v1/oauth2/token/userinfo
https://api.sandbox.paypal.com/v1/oauth2/certs
In app client settings I have auth code grant flow and implicit flow enabled. I have custom domain setup. I provided paypal client id and secret
My guess is if I'm able to somehow debug idpresponse endpoint I should be able to solve the problem. Is there any way to do that? Maybe cloudwatch?
I don't know about debugging Cognito's endpoints, but I had the same problem and fixed it by doing the following:
Go to your User Pool in AWS.
In the side navigation under Federation, select Attribute mapping.
Click the tab of the identity provider you're having issues with (in my case it was Google).
There should be three columns, Capture, Google attribute, and User pool attribute. Make sure all of the attributes that are checked in the Capture column are mapped to an attribute in the User pool attribute column.
UPDATE:
After submitting this answer, I realized that the checkboxes in the Capture column are not checked by default. If you marked any attributes as required in the Attributes section of your user pool, then you need to map those attributes to the attributes provided by your external identity providers.
For example, I marked email as a required attribute in my user pool settings. So, when I added Google as an identity provider, I had to go to Federation->Attribute mapping, click on the tab for Google, check the box in the Capture column next to email, and select Email from the dropdown box in the User pool attribute column.
After taking these steps, the sign in work-flow worked for me.
My guess is the auth flow works just fine between Cognito and your identity provider, but Cognito doesn't know how to map the attributes returned from the identity provider to the attributes you have set in your user pool (in General settings->Attributes under the Which standard attributes are required section).
I am attempting to work with the Autotask Api, would anyone be willing to share some "Postman" Calls to see if i am on the right track?
here is what I have tried.
Post - https://webservices/autotask.net/atservices/1.6/getZoneInfo?
Key -------------- Value
UserName ------------ myApiUserName#email.com
Assuming my credentials are correct (im not sharing here) can you help me to understand why this does not work?
I too am in the early stages of looking into the Autotask API, I can sucessfullly connect to the API from Postman...
You require an API User Account [not a normal user account]
The password for the API Account [obviously]
And a Tracking Indentifier
The API user can be created within Autotask # Admin> features & settings> Resources/users> new Users. You will need to give the new user account the security level API User (System) once you have created the API user account you will need to generate the Tracking Identifier by clicking the Custom [internal intergration] radio button in the bottom right hand corner. Then click the Generate button. Once armed with these three bits of information you will need to goto Postman's Authorization tab and enter the API user credentials. Then goto to the Headers tab and Add the
Key: TrackingIdentifier
Value: <Your Tracking Identifier>
as this has to be included in the header of all GET, POST, DELETE etc. requests.
Finally you will need to be sure you are using the correct url as depending on where your Autotask tenancy is sitting the url will be different. [take a look at your url whilst logged into Autotask].
Hope this is helpful...
I have enabled CTRL+ALT+DELETE secure attention sequence (SAS) for windows logon using local security policy. (secpol.msc , Security Settings->Local Policies->Security Options->Interactive Logon: Do not require CTRL+ALT+DEL -> Disabled )
Currently the machine is using a facial based custom credential provider for login in Windows 10. In the current setup if the custom credential provider fails during authentication, it falls back to normal windows based logon (Password / Pin).
I have disabled the password, pin based mechanism through the group policy ( gpedit.msc, Computer Configuration ->Administrative Templates->System->Logon , Exclude Credential Providers ). This works fine as password and pin cannot be used for authentication. But the login page is still displayed.
How to always go back to Ctrl+Alt+Del logon page if the custom credential provider fails to do any authentication so that the user can retry ?
Is it possible to Control through group policy? Do I have to manage through the credential provider source so the fallback always goes back Ctrl+Alt+Del page.
Additional Info: https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2003/cc780332(v=ws.10)
Ref section - Winlogon Desktop Dialog Boxes:
In other words it is about switching from "Log On to Windows" desktop "Welcome to Windows" desktop automatically.
Additional Info on the flow:
When Winlogon.exe detects the SAS (Ctrl+Alt+Del), it launches this LogonUI.exe process,which initializes our custom credential provider.
In the normal use case , when our credential provider succeeds , user enters his credentials and the LogonUI.exe process terminates.
Now in the second case, when our custom credential provider fails, desktop becomes blank or if fast user switching is enabled, it displays the switch user button.
In the correct use case , I have to fallback to SAS (Ctrl+Alt+Del)
*pcpgsr = CPGSR_RETURN_NO_CREDENTIAL_FINISHED;
return hr; // return to LogonUI
CPGSR_RETURN_NO_CREDENTIAL_FINISHED will return from your module to windows system without accepting your security structure. Also use unadvise to cleanup while returning from Serialization call.
Do you solve your issue?
I think in the new scenario of credential providers (versus GINA) it is impossible to control this behaviour.
If ctrl+alt+del is enabled there is no legal way to eliminate and/or simulate this secure attention sequence. Have a look at this article.
After creating an instance of parse server on AWS, I can see the configuration.
var api = new ParseServer({
databaseURI: "mongodb://root:gzkThVPNmUS5#127.0.0.1:27017/bitnami_parse",
cloud: "./node_modules/parse-server/lib/cloud-code/Parse.Cloud.js",
appId: "XXXXXXXaef",
masterKey: "XXXXX33150",
fileKey: "XXXXXXX7073",
serverURL: "http://XXXXX.us-west-2.compute.amazonaws.com:80/parse"
});
The problem is when I use the serverURL to my web browser, it asks user and password which I do know. I tried my user name and password from AWS but it does not allow me to login the parse dashboard.
This link helps: parse server credentials
User: user
The application password is randomly generated during the first boot. This password can be viewed as follows:
Log in to the AWS Cloud Console.
In the left navigation bar, select the "Instances -> Instances" menu
item.
Select your instance in the dashboard.
From the "Actions" drop-down menu, select the "Get System Log" menu
item.
Review the system log until you find the application password.
I had the same issue, which I have just resolved:
When looking into the AWS system log for the generated username user (by default) and password, make sure you manually type out the password that is generated when trying to login to the Parse dashboard.
Such copy and pasted clear-text passwords sent over the insecure http protocol doesn't work, and shouldn't work.