I have configured the authorize.net in my new magento 2.0.5. I have updated my sandbox api login id, transaction key, merchant md5, and changed the url into https://test.authorize.net/gateway/transact.dll for testing.
Also i have enabled the test mode and debug mode to track. While placing the order I'm receiving the error on alert box Please enter a transaction ID to authorize this payment.. While checking /var/log/debug.log transaction id (x_trans_id) was in 0. I suspect that the issue is with the transaction id.
You should not set your gateway to test mode or set test mode as true in your request.
Related
I am getting the following response when calling the /accounts/balances/get endpoint in the development environment. After getting this, I'll use update mode to get a new access_token. Once I swap in the new token, everything works fine for about an hour and then this error will occur again. I am 100% not making any updates on the bank side.
{ display_message: null,
error_code: 'ITEM_LOGIN_REQUIRED',
error_message: 'the login details of this item have changed (credentials, MFA, or required user action) and a user login is required to update this information. use Link's update mode to restore the item to a good state',
error_type: 'ITEM_ERROR',
request_id: 'redacted',
suggested_action: null }
Does the login associated with the Item have "perpetual OTP" enabled -- i.e., is it configured so that you need to enter a 2-factor authentication token every time you log in to your bank, even on a trusted device?
If so, this is expected behavior -- once your original session expires, Plaid requires a user to be present to provide a new token and create a new session to get fresh data.
If not, there may be an issue with the integration between Plaid and the specific financial institution. If that's the situation, you should file a support ticket with Plaid so we can investigate further.
We are working on an application, which is protected with spring security saml.
Authentication works fine, but there is one problem with the following workflow in production environment.
user requests the unprotected address www.server.com
response is a html page with an inline script that changes window.location.href to the saml protected page (service provider) www.server.com/app/action?param1=value1¶m2=value2
spring saml detects that authentication is needed and redirects the user to the login form (identity provider) on www.login-server.com
at this point the login form is the first page that is displayed to the user
user adds this login page as bookmark (including saml related url params for this http session) www.login-server.com/adfs/ls/?SAMLRequest=xxx&SigAlg=xxx&Signature=arGdsZwJtHzTDjQP1oYqbjNO
user works with the application...
at the next day the user opens this bookmark and login
IdP redirects to the SP but the belonging http session has already expired
Now we get the following exception in our application:
org.opensaml.common.SAMLException: InResponseToField of the Response doesn't correspond to sent message arGdsZwJtHzTDjQP1oYqbjNO
Any ideas how to handle this workflow so the user can use the application after successful login?
Thanks for your answers!
We have solved our issue with following changes to the spring saml configuration:
In bean with id successRedirectHandler (org.springframework.security.web.authentication.SavedRequestAwareAuthenticationSuccessHandler) we set the defaultTargetUrl to the init-Action of our application (including all request parameters). This url will be automatically used in case of IdP initiated SSO.
In Bean with id contextProvider (org.springframework.security.saml.context.SAMLContextProviderLB) we set storageFactory to org.springframework.security.saml.storage.EmptyStorageFactory. This disables the check of the InResponseToField.
When you applicate generated an AuthnRequest, the request has an ID which your application somehow keeps. The corresponding response from IdP must have InResponseTo attribute set to that same ID value so that your application can verify that the response is meant to be for the request it sent.
However, when your user bookmarked the adfs link that contains request (www.login-server.com/adfs/ls/?SAMLRequest=xxx...), your application had totally forgotten about that request. In other word, it no longer kept the request ID somewhere and couldn't verify response.
The solution is to tell your users not to bookmark the www.login-server.com/adfs/ls/?SAMLRequest=xxx... link. Instead, they must bookmark a link in your application where it can generate a new request and send to ADFS.
I am doing a POC where I need to integrate the Shibboleth SP with OKTA idp provider.I have completed all below steps documented on OKTA official site for this integration.
Install Shibboleth Service Provider
2.Configure the webserver to use Shibboleth
3.Configure Shibboleth to protect a specific folder Create an Okta SAML 2.0 Template application
4.Modify Shibboleth to use the metadata obtained from the Okta application 5.Modify the attribute-map.xml file within Shibboleth
to set the appropriate header variables
6.Restart everything
But there are details missing from the step 5 where I need to modify the atrribute-map.xml. when I fire my protected URI(hosted on apache) it is getting redirected to OKTA login page. But after user enters the user-id and password and clicks login I get a spinner on my browser and it never takes me to my protected site URI hosted on Apache. Any clues to fix this attribute-mapping in Shibboleth SP is highly appreciated.
If the page is not being redirected to SP, he problem need not be with attributes-map.xml
Endpoints could be incorrectly configured. Check
{web app uri}/Shibboleth.sso/Metadata to see if the endpoint URLs are correctly defined.
Check Shibboleth2.xml if entityID is correctly defined, this is the web application that Shibboleth is protecting.
Check {web app uri}/Shibboleth.sso/Session this displays if all the attributes that are being sent from Okta. You can make it display the values too by changing Shibboleth2.xml since it is just POC.
Finally comes attributes-map.xml where you can configure attributes as agreed with Okta. There are some default attributes like NameID that are pre-configured here. You can see the format in attribute-map.xml and in /Shibboleth.sso/Session and code to make use accordingly. For example
formatter="$NameQualifier!$SPNameQualifier!$Name"
If you are adding custom attributes a simple element as shown below should work as long as the name is matching the attribute name that Okta is sending.
This issue was resolved by doing proper configuration on the OKTA side .OKTA provides sam2.0 template app for integration with shibboleth .The below mentioned parameters of this template app were properly configured.
Post Back URL -
Name ID Format - Transient
Recipient -
Audience Restriction -
authnContextClassRef - PasswordProtectedTransport
Response - Signed
Assertion - Signed
Request - Compressed
Destination -
Attribute Statements - username|${user.userName}
Then our integration was succesful
I am writing a refund function for our ecommerce site and I'm getting error code 3033 : The RelatedSecurityKey is required.
I have checked and the documentation says this key should be returned when the original transaction was made. We save the details without any modifications to the database, but I can't find it. The return values for my test transaction are:
VendorTxCode=241****
&VPSTxId={EBA625AB-955E-75C8-4409-*********}
&Status=OK
&StatusDetail=0000 : The Authorisation was Successful.
&TxAuthNo=763****
&AVSCV2=SECURITY CODE MATCH ONLY
&AddressResult=NOTMATCHED
&PostCodeResult=NOTMATCHED
&CV2Result=MATCHED
&GiftAid=0
&3DSecureStatus=NOTCHECKED
&CardType=VISA
&Last4Digits=0006
&Amount=25.00
Any suggestions?
SecurityKey - Only present if Status is OK.
To register the initial transaction, you post to Sage Pay via the Transaction Registration URL (A1).
Sage Pay send a server reponse to the tranasction registration POST in the Server protocol (see A2 in Sage Pay Server Protocol). The response includes the following - VPSProtocol, Status, StatusDetail, VPSTxId, SecurityKey and NextURL.
[A Security key which Sage Pay uses to generate a MD5 Hash to sign the Notification message (step A3 from the Sage Pay Server protocol, which is the example you are providing in response to the Notification post via the Notification URL). The signature is called VPSSignature. This value is used to allow detection of tampering with notifications from the Sage Pay Server. It must be kept secret from the Customer and held in your database. Only present if Status is OK.] You need the SecurityKey incase want to refund against the transaction in future as this will become the RelatedSecurityKey.
The NextURL redirects the customer/shopper to the Sage Pay payment page.
Sage Pay then notify you via the NotificationURL with the VPSSignature. (A3)
You then acknowledge receipt of the post and the customer is redirected via the RedirectURL back to a page on your website.
Using OpenAM i am trying to protect an ADF application, i have installed the weblogic policy agent as documented.
i get prompted to login with the OpenAM screens however once logged in and redirected back to the application i get the following error
Error 403 -- Forbidden
The server understood the request, but is refusing to fulfill it. Authorization will not help and the request SHOULD NOT be repeated. If the request method was not HEAD and the server wishes to make public why the request has not been fulfilled, it SHOULD describe the reason for the refusal in the entity. This status code is commonly used when the server does not wish to reveal exactly why the request has been refused, or when no other response is applicable.
Is there any logs or anything i can look at to find the exact reasoning?
the only thing i can think of is its something to do with the ADF security.
By default the Agent is running in 'ALL' mode, which means it's also enforcing authorizations for URL (urlPolicy). So you have to create URL policies as well.
However URL policies often do not make sense for Web Apps, so you could change the agent to run in 'SSO_ONLY' or 'J2EE' mode.
BTW the agent debug log (log level set to 'message' in agent profile) will tell you why it's denying access.