I am having trouble finding a solution to this and would love to any thoughts or suggestions.
The overall aim is to dynamically generate a private link within an email, used to register/login users anonymously. Only those with a link will be able to access the app, and they will otherwise remain anonymous (i.e no link to their email address - identified only by the number included within the dynamic link). Obviously, if they share this URL, anyone can log in as them.
I would like to generate some sort of embed code that customers may copy/paste as part of an email template. Ideally, This code would dynamically create a unique identifier for each recipient on delivery. We will not be able to send a dedicated email to do this. For example, a customer clicks 'Generate embed link' within the admin panel. They will be provided with a html string that they may include within their email template, eg:
<html :href="www.myapp.com/customer1/register/batch1/{{dynamic_id}}"></html>
On receiving this email, the link may look like this:
<html :href="www.myapp.com/customer1/register/batch1/7877346"></html>
The idea is that the user could click the link and automatically register/log in using this URL. It is crucial that no one can see this URL other than the recipient, and there is no way of linking the sent email back to the dynamically generated ID. GDPR, bah :(
Hope this makes sense. Happy to hear alternative solutions or limitations here.
Thanks in advance.
We're generating some emails programmatically. We need to include a hyperlink that takes people to a page on website A, but we want to use website B to track their click before redirecting.
Is it safe to show the URL to website A, but in a hyperlink that really takes them to website B? That is, something like this:
Here's the page you wanted:
<a href="http://website-b.com/someTrackingToken">
website-a.com/theThingYouWereExpecting
</a>
... or does this look sufficiently scam-like that some email clients might object to it?
Note:
We specifically do want the website-a.com URL to be visible to the email recipient.
The sites are on different domains.
You can set the visible link and the href property to be two totally different things and there's usually little to no consequences, this is pretty standard for most mailers that need tracking.
The thing is, why not just wrap some text instead of a literal link? Present it as a button if you're worried about "click ability".
If you want to present a link that's nearly the same, why not just append some parameters on the end that trigger the tracking action? Like /x vs /x?token=XXX where you can grab that and and process it at any point of handling the request. Just suppress the display of that in the raw URL you're showing.
I'm looking to pass data from a form into an iFrame, but I have a slight problem.
The form page I can edit with no restrictions
The page I send the data to I cannot edit unless its html or JavaScript
The data needs to end up in an iframe within this page, which I can edit with no restrictions
I'm incorporating a search function into a CMS system which is why I cannot edit the iframe's parent page, and why I am using iframes at all.
At the moment the data sends to the parent page but is not picked up within the iframe, I am sending via the POST method.
I got it..
Added and extra page which converted the post data into session data,
if anyone knows a better way i would like to hear it though.
And they are the same domain, but editing the CMS system would have taken ages to look through as its not mainstream or developed by me.
Maybe I'm oversimplifying the problem, but can't you use the "target" attribute of the form tag to post to the Iframe?
I am wondering if anyone can give a "best practices" response to using blank HTML form actions to post back to the current page.
There is a post asking what a blank HTML form action does here and some pages like this one suggest it is fine but I'd like to know what people think.
The best thing you can do is leave out the action attribute altogether. If you leave it out, the form will be submitted to the document's address, i.e. the same page.
It is also possible to leave it empty, and any browser implementing HTML's form submission algorithm will treat it as equivalent to the document's address, which it does mainly because that's how browsers currently work:
8. Let action be the submitter element's action.
9. If action is the empty string, let action be the document's address.
Note: This step is a willful violation of RFC 3986, which would require base URL processing here. This violation is motivated by a desire for compatibility with legacy content. [RFC3986]
This definitely works in all current browsers, but may not work as expected in some older browsers ("browsers do weird things with an empty action="" attribute"), which is why the spec strongly discourages authors from leaving it empty:
The action and formaction content attributes, if specified, must have a value that is a valid non-empty URL potentially surrounded by spaces.
Actually, the Form Submission subsection of the current HTML5 draft does not allow action="". It is against the spec.
The action and formaction content attributes, if specified, must have a value that is a valid non-empty URL potentially surrounded by spaces. (emphasis added)
The quoted section in mercator's answer is a requirement on implementations, not authors. Authors must follow the author requirements. To quote How to read this specification:
In particular, there are conformance requirements that apply to producers, for example authors and the documents they create, and there are conformance requirements that apply to consumers, for example Web browsers. They can be distinguished by what they are requiring: a requirement on a producer states what is allowed, while a requirement on a consumer states how software is to act.
The change from HTML4—which did allow an empty URL—was made because “browsers do weird things with an empty action="" attribute”. Considering the reason for the change, its probably best not to do that in HTML4 either.
Not including the action attribute opens the page up to iframe clickjacking attacks, which involve a few simple steps:
An attacker wraps your page in an iframe
The iframe URL includes a query param with the same name as a form field
When the form is submitted, the query value is inserted into the database
The user's identifying information (email, address, etc) has been compromised
References
Bypassing CSRF protections with ClickJacking and HTTP Parameter Pollution
This will validate with HTML5.
<form action="#">
IN HTML 5 action="" IS NOT SUPPORTED SO DON'T DO THIS. BAD PRACTICE.
If instead you completely negate action altogether it will submit to the same page by default, I believe this is the best practice:
<form>This will submit to the current page</form>
If you are sumbitting the form using php you may want to consider the following. read more about it here.
<form method="post" action="<?php echo htmlspecialchars($_SERVER["PHP_SELF"]);?>">
Alternatively you could use # bear in mind though that this will act like an anchor and scroll to the top of the page.
<form action="#">
I think it's best to explicitly state where the form posts. If you want to be totally safe, enter the same URL the form is on in the action attribute if you want it to submit back to itself. Although mainstream browsers evaluate "" to the same page, you can't guarantee that non-mainstream browsers will.
And of course, the entire URL including GET data like Juddling points out.
Just use
?
<form action="?" method="post" enctype="multipart/form-data" name="myForm" id="myForm">
It doesn't violate HTML5 standards.
I used to do this a lot when I worked with Classic ASP. Usually I used it when server-side validation was needed of some sort for the input (before the days of AJAX). The main draw back I see is that it doesn't separate programming logic from the presentation, at the file level.
I use to do not specify action attribute at all. It is actually how my framework is designed all pages get submitted back exact to same address. But today I discovered problem. Sometimes I borrow action attribute value to make some background call (I guess some people name them AJAX). So I found that IE keeps action attribute value as empty if action attribute wasn't specified. It is a bit odd in my understanding, since if no action attribute specified, the JavaScript counterpart has to be at least undefined. Anyway, my point is before you choose best practice you need to understand more context, like will you use the attribute in JavaScript or not.
When you put empty action then some security filtration consider it malicious or phishing. Hence they can block your page. So its advisable not to keep action= blank.
This is my first time posting - I greatly appreciate any and all guidance on this subject.
Background: I am building a Real Estate web site. I would like to use the free IDX data provided by my local MLS board. The MLS board does not allow me the option of displaying a predefined search and only provides me with a link to the search field. after filling out the search field, I am able to view the results.
Goal: I would like to bypass this step and frame the results page into a GoDaddy website I am building, which supports HTML.
Here is a link to the search page:
http://fgcmls.rapmls.com/scripts/mgrqispi.dll?APPNAME=Fortmyers&PRGNAME=MLSLogin&ARGUMENT=vBSJvLQtMcbg7F0O0KnXDiggv%2F12B0S6Ss9wv4510QA%3D&KeyRid=1
I am trying to only show the listings that appear in my neighborhood. Options include:
1. Property Type - Residential
2. GEO Area - FM11
3. Developments: Fiddlesticks Country Club
Once this criteria is entered, I have the page needed to make this project work.
Thank all of you for taking the time to read this and for the time you spend helping me out.
Best regards,
Chris
Without looking at the page itself, it's probably doing a "POST" operation to give the form to the website. You should be able to use javascript (maybe jquery or some other ajax framework) to do this for you in the frame and have it display the results.
-Adam
So long as this is a POST form and they aren't doing a lot of strict referrer checking, the following should work:
Replicate the form on your own site.
Make a few minor changes to automate a few of the fields to better serve your geographic area/company.
Ensure everything is a full path and not relative to the server handling the query.
You will probably end up changing a lot of the text/select fields to hidden fields with pre-set values to keep it simple for end-users. The server handling the request won't know the kind of field it came from, just the value and name.
I took a look at the page HTML, the form posts is defined thusly:
<FORM action="/scripts/mgrqispi.dll" method="POST" name="InputForm" />
you may be able to create your own form defined like this:
<FORM action="http://fgcmls.rapmls.com/scripts/mgrqispi.dll" method="POST" name="InputForm">
</FORM>
You will have to go through the HTML on the page you provided to get the appropriate ID's and Name's of the form elements you are interested in. Its possible their processing page checks to ensure its their form that is submitting to it, in which case this wouldn't work.
good luck.