基于ASP.NET+jQuery的外部站点新窗口打开并传数方案咨询

Hey Mike, let’s tackle your question head-on—you’ve got solid alternatives to just query strings, and there’s a clear optimal approach for your scenario, especially with future encryption in mind.

Can you use a form instead of query strings? #

Absolutely! Form submissions via POST are a totally valid way to send data to an external site while opening it in a new window. This solves the query string length limit issue entirely, since POST data isn’t tied to URL character caps.

Why query strings aren’t ideal here #

Query strings have two big drawbacks for your use case:

• Length limits: Different browsers and servers enforce varying caps (IE famously has a 2083-character limit, while modern browsers are more lenient but still not unlimited). With lots of data, you’ll hit this wall quickly.
• Visibility: Data is exposed directly in the URL, which is fine for non-sensitive data now, but becomes a problem if you need to encrypt later—even encrypted data in the URL is still visible to anyone looking at the address bar or server logs.

The optimal approach: Dynamic POST form (jQuery/ASP.NET) #

The best method is to dynamically create a form (either client-side with jQuery or server-side in ASP.NET) that submits data via POST to the external site, with target="_blank" to open it in a new window. Here’s how to implement both versions:

Client-side (jQuery) example

Great if your data is already available on the frontend:

function openExternalSiteWithPrefill() {
    // Your data object—populate this with your actual fields
    const prefillData = {
        fullName: "Jane Smith",
        userEmail: "jane.smith@example.com",
        addressLine1: "123 Main St",
        city: "Anytown",
        // Add as many fields as you need
    };

    // Create the form element
    const $submitForm = $('<form>', {
        method: 'POST',
        action: 'https://external-site.com/your-target-page',
        target: '_blank' // Critical for opening in new window
    });

    // Add hidden inputs for each data field
    $.each(prefillData, function(fieldName, fieldValue) {
        $('<input>', {
            type: 'hidden',
            name: fieldName,
            value: fieldValue
        }).appendTo($submitForm);
    });

    // Append form to the page, submit it, then clean up
    $submitForm.appendTo('body').submit().remove();
}

Just call this function when the user clicks your link or button.

Server-side (ASP.NET) example

Perfect if your data comes from the backend:

<%-- In your .aspx file --%>
<form id="externalPostForm" runat="server" method="POST" 
      action="https://external-site.com/your-target-page" target="_blank">
    <asp:HiddenField ID="hfFullName" runat="server" />
    <asp:HiddenField ID="hfUserEmail" runat="server" />
    <asp:HiddenField ID="hfAddressLine1" runat="server" />
    <!-- Add more hidden fields for your data -->
</form>

<script>
    // Trigger form submission when needed (e.g., on button click)
    $('#<%= externalPostForm.ClientID %>').submit();
</script>

In your code-behind, set the values of the hidden fields before the page renders.

Key considerations for future encryption #

Since you mentioned possible encryption later, this approach works seamlessly:

• Encrypt field values: Before populating the hidden inputs, encrypt each value using a symmetric algorithm like AES (make sure the external site has the matching decryption key).
• Avoid URL exposure: Unlike query strings, encrypted POST data isn’t visible in the address bar, adding an extra layer of security.
• Coordinate with the external site: Confirm they accept POST data for pre-filling, and align on parameter names and decryption logic if you add encryption later.

Final notes #

• Cross-domain isn’t an issue here: Form submissions to external domains are allowed by browsers (unlike AJAX requests, which require CORS), so you won’t run into blocked requests.
• If the external site only supports GET requests (unlikely, but possible), you can still encrypt your query string data to mitigate length/visibility issues—but POST is always better for larger datasets.

内容的提问来源于stack exchange，提问作者Mike