What's the meaning of "error_subcode" in error information?
Can we make sure the error type by Analyzing "error" and "error_subcode"?
Do facebook has official explanation about the "error_subcode"?
As described in an old stub from Facebook
Along with a human-readable message, error responses include an error_subcode that describes the nature of the error. Although you can generally only respond to these errors by reauthenticating the user, you can use these subcodes for internal logging purposes or to better explain why you're asking the user to log in again. The possible codes and their meaning are below:
`error_subcode` Meaning
456 The session is malformed.
457 The session has an invalid origin.
458 The session is invalid, because the app is no longer installed.
459 The user has been checkpointed. The error_data will contain the URL the user needs to go to to clear the checkpoint.
460 The session is invalid likely because the user changed the password.
461 The session is invalid, because the user has reinstalled the app.
462 The session has a stale version.
463 The session has expired.
464 The session user is not confirmed.
465 The session user is invalid.
466 The session was explicitly invalidated through an API call.
467 The session is invalid, because the user logged out.
468 The session is invalid, because the user has not used the app for a long time.
Related
I couldnt figure out how to get the status of the transactions i.e "Fail with error "001010".
The ability to show error message, or the revert reason. depends on the EVM client (GoEthereum, Erigon, Ganache, Ethereum Tester, etc.) There is no bulletproof "standard".
The clients store only the receipt field status that is 0 or 1 (=success)
The clients do not store the revert reason (I might be wrong on this one and this has changed lately)
To get the actual error message you need to replay the transaction and a certain block height using a special eth_call JSON-RPC.
Here is a Javascript library for doing it and a related blog post about the topic.
I have requested a public ACM certificate and I have selected the DNS validation method. After requesting the certificate it went to Pending validation state. I have created a hosted zone in Route 53 with the same domain name which I have used for my certificate. After creating the certificate I got the option "Create record in Route 53". I have created the record in Route 53 with the CNAME and it displayed as " Success
The DNS record was written to your Route 53 hosted zone. It can take 30 minutes or longer for the changes to propagate and for AWS to validate the domain and issue the certificate.". But the status of the certificate is not getting changed and it is still in pending validation only. After some time the "Create record in Route 43" option is getting enabled again. I have tried the same process multiple times almost one day but the status is not getting changed. Can someone please help to fix the issue.
In the AWS Console (Web UI), on the Certificate Manager page,
Expand the certificate that is pending
Expand the table that has domain and validation status
Click the blue button that says "Create record in Route 53" (you can also do this manually)
Give it about 10 minutes
Or follow these instructions from AWS - Why is my AWS Certificate Manager (ACM) certificate DNS validation status still pending validation?
Having the same issue here and I found out that my problem is in the NS record in my domain. My mistake was I didn't update the Name Servers in my domain, what I did was the opposite. I updated the values of the NS record in R53 based on the NS on my domain then I realized that the right thing to do was to update your NS (Name Servers) of your domain to the values of the NS record in R53. Haha (english is not my native language btw).
Just make sure you have the correct Name Servers and correct CNAME suggested by ACM. I waited a day before and still Pending Validation, but when I fixed it it took only a few minutes for my certificate to be issued.
What I would do is:
Verify that the DNS returns what is expected.
For that you can use dig (Linux) or nslookup (Windows), or even better > https://www.digwebinterface.com
If you don't get what is expected, you need to reconfigure the DNS.
Once it is verified, wait a little bit (10 min to 2h I'd say).
Something to read while you wait:
https://docs.aws.amazon.com/acm/latest/userguide/acm-regions.html
https://docs.aws.amazon.com/acm/latest/userguide/dns-validation.html
https://aws.amazon.com/premiumsupport/knowledge-center/acm-certificate-pending-validation/
https://docs.aws.amazon.com/acm/latest/userguide/domain-ownership-validation.html
Here is what I gathered from the RFC 5321:
4.1.1.5. RESET (RSET)
This command specifies that the current mail transaction will be aborted. Any stored sender, recipients, and mail data MUST be discarded, and all buffers and state tables cleared. The receiver MUST send a "250 OK" reply to a RSET command with no arguments. A reset command may be issued by the client at any time. It is effectively equivalent to a NOOP (i.e., it has no effect) if issued immediately after EHLO, before EHLO is issued in the session, after an end of data indicator has been sent and acknowledged, or immediately before a QUIT.
The emphases are mine. This says that if we receive the RSET after the end of data indicator ".", but before we sent the acknowledgement, then we must discard the content of the message, which is currently being delivered. This does not seem practical. Moreover, the server can easily acts as if it received the RSET after he sent the acknowledgement - the client would not be able to know. Trying to know what is usually done, I found this discussion https://www.ietf.org/mail-archive/web/ietf-smtp/current/msg00946.html where they say:
Under a RFC5321 compliant "No Quit/Mail" cancellation implementation, after
completing the DATA state, the server is waiting for a pending RSET, MAIL
or QUIT command:
QUIT - complete transaction, if any
MAIL - complete transaction, if any
perform a "reset"
RSET - cancel any pending DATA transaction delivery,
perform a "reset"
drop - cancel any pending DATA transaction delivery
We added this support in 2008 as a local policy option (EnableNoQuitCancel)
which will alter your SMTP state flow, your optimization and now you MUST
follow RSET vs QUIT/MAIL correctly. RSET (after DATA) aborts the
transaction, QUIT/MAIL (after DATA) does not. RSET is not an NOOP at this
point.
The specification says that discarding is a MUST. However, the above extract suggests that in practice it is interpreted as a MAY. I could look at the code of known implementations of SMTP/LMTP, such as Dovecot, but perhaps someone already reviewed that and this would save me time.
The text says "end of data indicator has been sent and acknowledged" which suggests that the client has received the server's response to the DATA command. Since the base protocol doesn't support command pipelining, I don't think sending anything after DATA but before the server's response (after the dot which terminates the DATA but before you receive a reply from the server) is well-defined behavior.
Personally, I can't think of any more reasonable server behavior than "pretend it didn't happen."
The answer is here : https://www.rfc-editor.org/rfc/rfc1047 . They basically says that you can acknowledge before you start the processing and it is actually recommended to do so. This does not violate RFC 5321. Of course, more information on this issue would be useful, but I am happy with rfc1047.
I am new to EMV development. My question is regarding Tag 91 (Issuer Authetication Data) which is sent by Issuer in EMV response. In my case, when tag 91 is missing in response packet then chip card decides to decline the transaction even if issuer has approved transaction online. So I am wondering whether Tag 91 is a mandatory tag which needs to be sent by issuer each time it approves a transaction online and what is industry wide understanding about it. Please let me know thoughts on it.
Also, In my case, Application Interchange Profile Byte 1, Bit 3 = 1 which means external authentication is required.
Are you working for Card Application or Terminal Application ?
Issuer authentication always have to be performed unless you are doing a partial chip implementation. I am sure you know that it is an additional level of security that ensures that the response came from the correct issuer.
When AIP B1B3 is on, it means card will expect tag 91.
In some cases it is even default. eg. D-PAS( Diners/Discover) AIP B1B3 is off, since it does not support External Authenticate. It is verified during second Gen AC. In such cases if the issuer wants card to not decline the transaction when ARPC not present, in the ACO( Application configuration Option), it is explicitly mentioned about partial chip implementation.
Check each payment scheme card and terminal specifications manual careful before you implement, as any loop holes in implementation may help a fraudster skip the security you wish to provide.Thumb rule, if you get ARPC from issuer, always sent it to card. Let the card decide.
From Card Application side I can add that "Application Interchange Profile Byte 1, Bit 3 = 1 means external authentication is supported, but not required. What does it mean ? Card may support Issuer Authentication, but may not required it for online transaction (issuer authentication can be mandatory or optional in card internal parameters). I.e. for optional it would be great to do auth, but if not - no problem, do online. And if Issuer have not sent tag 91 card may aprove transaction.
I am using Cas overlay approach. From time to time I get problems with getting into /cas/services/manage .
"
Access Denied
UsernameNotFoundException::aaa
"
Sometimes it actually lets me in. In deployerConfigContext.xml I have declared "aaa" user.
<sec:user-service id="userDetailsService">
<sec:user name="aaa" password="aaa" authorities="ROLE_ADMIN" />
</sec:user-service>
What can be causing this inconsistent behaviour?
excerpt from logs showing that authentication went ok
2013-07-31 11:53:05,332 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - <org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler successfully authenticated [username: aaa]>
2013-07-31 11:53:05,333 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - <Resolved principal aaa>
2013-07-31 11:53:05,333 INFO [org.jasig.cas.authentication.AuthenticationManagerImpl] - <org.jasig.cas.authentication.handler.support.SimpleTestUsernamePasswordAuthenticationHandler#4b4bc1e authenticated aaa with credential [username: aaa].>
This sounds like user aaa is not available in your Authentication Handler. The XML code you supplied just authorizes that user to use that service, it does not allow that user to authentication into CAS.
The inconsistency could be that your Authentication Handler (database/LDAP/in memory to name a few) is not available at the time of authentication.