I was testing my site on W3C validator when I found some errors like:
"id" must be a single token
I've been wondering what's the fix but couldn't get an answer so if u can fix that would be appreciated.
Here's the code that gives me the error:
<form action='' id='contact form'>
It means that id should look like this:
<form action='' id='contact_form'>
E. g. without any whitespaces in value of id attribute. Also, it should be unique.
You haven't specified whether you are validating your document against HTML4 or HTML5. And there are some differences in specs for id in HTML4 and HTML5 - you can read about both here:
HTML 5:
http://www.w3.org/html/wg/drafts/html/master/dom.html#the-id-attribute
HTML 4.0:
http://www.w3.org/TR/REC-html40/struct/global.html#h-7.5.2
http://www.w3.org/TR/REC-html40/types.html#type-name
Related
Opayo returns from our payment request asking us to contact https://www.rsa3dsauth.co.uk/3ds2/cReqWebBased?issuer=barclays" for 3D Secure auth, so we send this:
<form id="c-form" method="POST" action="https://www.rsa3dsauth.co.uk/3ds2/cReqWebBased?issuer=barclays">
<input type="hidden" name="creq" value="*removed for data protection*" />
<input type="hidden" name="threeDSSessionData" value="tQtpVHCcCVGEhPNDaeCtMK9I%2fREJERnarovmuZPsM4M6xy6gks9rOYix36waoxOn1wukcobCFbfd2jpmVDVDwZjrd3MzJtmpyFDEAu5R9azVveH6kBEXc5F2ETnFijQfEj5l6EzmH7EnMzbTlFHgbkDGR%2fH9CtURo0K2VSUKHN4%3d" />
<script>
document.addEventListener("DOMContentLoaded", function()
{
var b = document.getElementById("c-form");
b && b.submit();
});
</script>
</form>
And we get back
POST https://xxxxx.xxxxxxx.xxx/api/payment/3dsecurechallenge?eid=ctl00_cphMain_Payment_SagePay_ThreeD
cres=*removed for data protection*&threeDSSessionData=
Note there is nothing following &threeDSSessionData=, where it should be returning our string back to us.
The documentation says:
Anyone else having this issue?
Just to add some more context - we had the same issue but only with rsasecure.co.uk at the start of June. Other banks worked correctly. We have an open case with Opayo about this but there has not been a lot of communication.
We turned off 3DS while this issue is occurring but have been advised to try again today (23.07.21) as it may have been an issue at the banks side.
threeDSSessionData seems to be URL encoded in the input tag. Have you tried this without the URL encoding? I believe it should only be base64 encoded.
I've now received a response from Opayo. I also think they may have changed something because I'm positive I tried this previously and it didn't work...
threeDSSessionData is the base64 encoded of VPSTxId (including the curled braces). It is not base64url encoded - talking about url encoding is a massive red herring because the browser auto submit handles this without us having to do anything.
Here's an example that worked for me.
I curl post the card details to vpsdirect-register.vsp (or whatever flavour you're using). This must include a ThreeDSNotificationURL value that contains the URL of the your callback page.
The following response was received.
Status=3DAUTH
StatusDetail=StatusDetail=2021 : Please redirect your customer to the ACSURL, passing CReq.
VPSTxId={1F3F8015-FFEB-E897-0643-58841AD5DB03}
ACSURL=https://test.sagepay.com/3ds-simulator/html_challenge
CReq=ewogICJtZXNzY...iA6ICIwNSIKfQ
I base64 encode the VPSTxId value into a threeDSSessionData value and get the customers browser to autosubmit the following form
<form action="https://test.sagepay.com/3ds-simulator/html_challenge" method="post" id="autopostform">
<input type="hidden" name="threeDSSessionData" value="ezFGM0Y4MDE1LUZGRUItRTg5Ny0wNjQzLTU4ODQxQUQ1REIwM30=">
<input type="text" name="creq" value="ewogICJtZXNzY...iA6ICIwNSIKfQ">
</form>
Customer will then do the necessary gubbins and the callback URL will have something similar to the following posted to it
cres=ewogICJtZXNzYWd...OiAiWSIKfQ
threeDSSessionData=ezFGM0Y4MDE1LUZGRUItRTg5Ny0wNjQzLTU4ODQxQUQ1REIwM30=
Both of these values are base64 encoded (the cres actually contains the acsTransID that was in the original response). We now need to base64 decode the threeDSSessionData back into a VPSTxId which we then need to curl post along with the (still encoded) cres value.
VPSTxId={1F3F8015-FFEB-E897-0643-58841AD5DB03}
CRes=ewogICJtZXNzYWd...OiAiWSIKfQ
Hopefully that'll give us a successful response and the transaction should go through.
In short it's a complete pita. In reality the encoding element should be dealt with via Opayo's API rather than us needing to code this up.
Edit: Original Reply
Yes! We flicked over to v4 with 3DSv2 last week and have had a couple of dozen customers reporting that they try to pay, and basically just returned back to the checkout. Looking at one now for barclays, but have had others too - including one where they 3dauth and don't get returned to our checkout at all...
I am trying to get the value from a hidden input field. I researched and found many sites ( including instances on this site ) showing great examples. When I try them, I am not able to retrieve the value from this hidden field using the methods I have learned. I have tried both an xpath extractor and a regular expression extractor, but neither one retrieves the value from the hidden field.
Also, I will note that in the tree on the left side in JMeter, I put the extractors as a child to the HTTP Request where the token first appears. Are the extractors supposed to be children or are they supposed to be at the same level as the HTTP Request, but just after it in the flow of the test?
==============================
Here, I will explain my set up. There is an HTTP request from a form. There is a token on the form. I need to get the value for this token. Here is the html for the page where the token appears:
<form action="/folder1/part1/save/12345-1234-1234-1234-123456789012" method="post" name="mgr" id="mgr" >
<input type="hidden" name="token" value="1234-12-12-12-1234" id="token" />
==============================
For the Regular Expression Extractor, I have tried all of these, one at a time for each test run:
//input[#type="hidden" and name="token"]/#value
//input[#type="hidden"][#name="token"]/#value
//input[#type="hidden"]/[#name="token"]/#value
//input[#type="hidden"][#name="token"]/#value/[#id="token"]
//input[#type="hidden"]/[#name="token"]/#value/[#id="token"]
For the XPath Extractor, I have tried all of these, one at a time for each test run:
//[#id="token"]
/html/body/div/div[2]/div/form/input[1]
//html/body/div/div[2]/div/form/input[1]
Try this one: //input[#type="hidden" and #name="token"]/#value
Also, you could test your expressions exactly in JMeter. For example, this xpath extraction you could check in XPath Tester element in View Result Tree Listener. There you could find Regexp Tester too
Validation in Spring 3.x using #Valid annotation:
Below is snippet from the messages_en.properties. I have a form having Username and Password field. When user does not enter anything in Username field, it displays both these messages one below other.
NotEmpty.loginBean.username=Username cannot be Empty
Size.loginBean.username=Size must between 5 to 50 characters.
Any HTML tag given in the message.properties is not interpreted.
NotEmpty.loginBean.username=<li>Username cannot be Empty</li>
Above would display <li> as it is.
Questions:
1) Is there any ways to interpret HTML tag and display its output?
2) Can i show single message though both validation fails?
Ad. 1) Yes, use htmlEscape="false":
<form:errors path="nip" cssClass="error" htmlEscape="false" />
Ad. 2) This is actually JSR303's Achilles' heel - it can be done, but is neither easy nor clean (see this issue). Order of validating each annotated field is undefined, so trick is to use #GroupSequence and custom groups like described here or here.
Alternative solution would be to use custom annotation with #ReportAsSingleViolation, but it will not distinct NotEmpty and Size errors as it'll have its own error message.
Should the link attribute rel="canonical" validate against html5?
It is the first time I am using this and I am getting the following validation errors:
"Bad value canonical for attribute rel on element link: Keyword canonical is not registered."
It kind of suggests it shouldnt although I cant find any concrete documentation on this.
Edit - Here is the line that is throwing the validator off:
<link rel="canonical" href="http://dev.local/" />
I have tried it with and without the closing slash
Validator is marking canonical invalid because canonical is a recent addition (as Gutmann pointed out) and the validation tool does not update real time. The W3C tells us why canonical is on the Micorformats wiki but does not validate. It is because the updates of wiki data in the validator are manual.
You will see this in the validation reporting:
"A whitespace-separated list of link types listed as allowed on in the HTML specification or listed as an allowed on on the Microformats wiki without duplicate keywords in the list. Note that updates of the wiki data in the validator are manual and do not happen in real time"
This will validate on their next manual update.
There is no definition for the canonical rel in the HTML5 spec, but it does also say that:
The rel attribute has no default value. If the attribute is omitted or if none of the values in the attribute are recognized by the user agent, then the document has no particular relationship with the destination resource other than there being a hyperlink between the two.
So, it's not technically conforming HTML5, but it will simply be ignored by UAs which don't understand it.
Use this data-rel
<link data-rel="canonical" href="http://dev.local/" />
In error description they do reference Microformats wiki as list of valid link types, their list contains "canonical" link type.
I believe that this a temporary bug in validator because it reported error for rel="canonical" only on my HTML5 website, but not on my other XHTML website.
From what I can gather from the output of the validator and the part of the spec that defines the link's rel attribute I'd say the validator is marking the document as invalid due to the "canonical" type being only a proposal and not part of the official linkTypes right now.
At the same time that page also says ...
Types defined as extensions in the
Microformats wiki existing-rel-values
page with the status "proposed" or
"ratified" may be used with the rel
attribute on link, a, and area
elements in accordance to the "Effect
on..." field. [MFREL]
The validation message refers to this list of currently valid extensions to the "official catalog".
Up until June 2 this list did not contain the canonical link type so the validator was IMO correct in marking the document as invalid.
But now that the canonical type is is in the list of proposed types, I think this is just a matter of time before also the validator will recognize it :-)
I developed a web page and now i am validating it with w3c HTML4.0... I got one error it says
Error Line 30, Column 57: there is no attribute "DATA-FLEXMENU"
href="about.php" class="mainlink" data-flexmenu="flexmenu1">About Us</a></div>
You have used the attribute named above in your document, but the document type you are using does not support that attribute for this element. This error is often caused by incorrect use of the "Strict" document type with a document that uses frames (e.g. you must use the "Transitional" document type to get the "target" attribute), or by using vendor proprietary extensions such as "marginheight" (this is usually fixed by using CSS to achieve the desired effect instead).
Any ways of getting rid of this error .... Any suggestion...
data attributes are present in HTML5.
see HTML 5 data- Attributes
Either you can change the doctype to html5 or remove the data attribute.
You can specify HTML 5 doctype like
<!DOCTYPE html>
As unhelpful as it will sound, either remove the attribute "data-flexmenu" from your markup, or accept a non-valid result.
The results are accurate, the A element in the DTD does not contain an attribute definition for the attribute data-flexmenu.
Alternatively you could define your own DTD and host it on a central server and reference that instead of the w3c one.
Or (as pointed out) use HTML5 DTD not HTML 4 DTD