Skip to main content
M
michaelsoutherton
Participant
August 31, 2021
Answered

KBA webform not auto-filling embed code URL parameters after KBA auth unless page reloaded

  • August 31, 2021
  • 2 replies
  • 928 views
  • Issue: the URL parameters from the webform embed code do not auto-fill on the first load of the form immediately following KBA auth. They only auto-fill after KBA auth AND a subsequent page reload. This makes URL parameter fields unreliable, and the form can't be finished if those fields are set as required AND read-only (for use in webhooks), meaning they rely on that value to auto-fill from the embed code.
  • Affects: KBA webforms with URL parameters
  • Does not affect: simple email auth webforms
  • Steps to reproduce:
    1. Create a webform that uses KBA auth.
    2. Add one custom field (e.g.: 'CustomField') that accepts a URL parameter and is read-only and required.
    3. Copy the the webform embed URL.
    4. Create a webpage and paste the embed code.
    5. Prepend some value for 'CustomField' to the embed code src attribute, e.g.:
      <iframe src="https://your-client-name.na4.documents.adobe.com/public/esignWidget?wid=your-wid-value*&hosted=false#CustomField=My custom field value" width="100%" height="100%" frameborder="0" style="border: 0; overflow: hidden; min-height: 500px; min-width: 600px;"></iframe>
    6. Open the webpage, and complete KBA auth.
      Immediately following KBA auth, you will see that the form is presented, but your CustomField value is not populated. Refresh the page, and then CustomField value will be populated.

 

See attached images for examples of it working (non-KBA auth) and not working (KBA auth).

This topic has been closed for replies.
Correct answer michaelsoutherton

The answer is: URL parameters do not work with authenticated web forms.

 

The details as to why are located at the very bottom of the Use URL parameters to fill web form fields part of the documentation, in the Properties And Limitations fine print:

quoteURL parameters do not work with authenticated web forms. Due to the use of URL Hash Fragments, if a web form is protected via a password or other authentication, the URL parameters are not passed back to the client after authentication is complete (the server never sees that part of the URL).

 

That answers the question, but I really wish they would find a way around this, because that essentially limits the feature of URL parameters to only a very small percentage of the products overall use cases. Could they not use query string parameters instead of, or in addition to, hashes? If a query string is provided, the auth server could detect it and pass it back to the client as either a query string or a hash. Maybe I'm missing something though.

 

We had a lot invested in a custom web form integration that relied on being able to pass dynamic values to a read-only field, but we missed this fine print in the documentation. Now we're trying to get thousands of KBAs we purchased refunded.

2 replies

M
michaelsouthertonAuthorCorrect answer
Participant
September 8, 2021

The answer is: URL parameters do not work with authenticated web forms.

 

The details as to why are located at the very bottom of the Use URL parameters to fill web form fields part of the documentation, in the Properties And Limitations fine print:

quoteURL parameters do not work with authenticated web forms. Due to the use of URL Hash Fragments, if a web form is protected via a password or other authentication, the URL parameters are not passed back to the client after authentication is complete (the server never sees that part of the URL).

 

That answers the question, but I really wish they would find a way around this, because that essentially limits the feature of URL parameters to only a very small percentage of the products overall use cases. Could they not use query string parameters instead of, or in addition to, hashes? If a query string is provided, the auth server could detect it and pass it back to the client as either a query string or a hash. Maybe I'm missing something though.

 

We had a lot invested in a custom web form integration that relied on being able to pass dynamic values to a read-only field, but we missed this fine print in the documentation. Now we're trying to get thousands of KBAs we purchased refunded.

M
michaelsouthertonAuthor
Participant
September 1, 2021

We've also tried a new webform using the password auth, and the same problem exists there as on KBA. Neither KBA nor password auth webforms will pass along the embed URL parameters on first load of the form after completing the auth part. This issue still does not occur on simple email auth webforms.

Terms & ConditionsAccessibility statement
Using the community Terms of use Privacy Cookie preferences Do not sell or share my personal information ad choicesAdChoices