Form Submissions from external IP Addresses not working

[bobi33]

Hi again :)

I found an issue regarding form submissions when used with IP address blocking in IIS. I'll try my best to explain it:

-I have IIS blocking turned on for all IP Addresses trying to access /umbraco (so no one can reach the back-end), except for a select few IP Addresses that allow access to /umbraco. -When you are using the network of one of the IP Addresses that is allowed to access the back-end the form submissions work great. -However, when you are on an external IP Address, which cannot access the back-end, form submissions don't show up. -It appears that it indicates that the form was submitted successfully, but not information shows up under "submissions" in the back-end.

Any ideas as to how to fix this? I'm using the release from April, 2017 (I cannot remember the version).

Thanks :)

[kjac]

Hi @bobi33,

Sounds like you've got a load balanced setup with a bunch of frontend servers? My guess is the submissions end up on the frontend servers then.

If that's the case, you've got one of two options:

1. Setup a file sharing/synchronization solution for ~/App_Data/FormEditor so the storage indexes are shared between all servers.
2. Change the storage index - check the docs for inspiration.

Note: I'm currently working on a few updates to the sample SQL storage index, which will allow submission updates and approval. It should be out in a few days and will require minor schema changes compared to the current sample index. If you end up changing the storage index and you use the SQL storage index as your baseline, you might want to wait until I have time to finish these changes.

[bobi33]

Hi,

I’m not sure if I have a load balanced setup with a bunch of front end servers. I’m using a GoDaddy VPS. The form submissions appear to work for the ip addresses that are allowed access to the Umbraco file through IIS IP address restrictions. But if you’re on an IP address that doesn’t have access to the Umbraco file (because of the iis IP address restriction - disallow all except...) the submissions don’t pass through even though it indicated a successful submission.

On Feb 28, 2018, at 03:37, Kenn Jacobsen notifications@github.com wrote:

Hi @bobi33,

Sounds like you've got a load balanced setup with a bunch of frontend servers? My guess is the submissions end up on the frontend servers then.

If that's the case, you've got one of two options:

Setup a file sharing/synchronization solution for ~/App_Data/FormEditor so the storage indexes are shared between all servers. Change the storage index - check the docs for inspiration. Note: I'm currently working on a few updates to the sample SQL storage index, which will allow submission updates and approval. It should be out in a few days and will require minor schema changes compared to the current sample index. If you end up changing the storage index and you use the SQL storage index as your baseline, you might want to wait until I have time to finish these changes.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[kjac]

Are you using the async rendering? You could try granting access to /umbraco/FormEditorApi/Public/SubmitEntry/, that's where the submissions are posted to. Although it doesn't sound like an access problem if the POST indicates success.

You could also try using the noscript rendering to rule out any access problems?

[bobi33]

I am using async rendering.

Perhaps I can try to allow IP access through IIS to that specific folder you mentioned. However, I cannot seem to find that folder: /umbraco/FormEditorApi/Public/SubmitEntry/. Where can I find it?

FormEditorApi is not found under the /umbraco folder.

The user receives a "success" notification on screen no matter what IP address they are using, but again, the form message is only available in the back-end under submissions if the user is on the IIS allowed IP address (for the /umbraco folder).

[kjac]

Hi @bobi33,

It's a virtual path to an API endpoint, so you won't find any physical files.

[bobi33]

Ah, ok.

So what do you think is the best way to resolve this? It’s clear that IIS IP blocking causes this. I don’t know if I can provide access to a certain file in the /Umbraco folder to fix this.

I’m lost :s

On Mar 1, 2018, at 01:58, Kenn Jacobsen notifications@github.com wrote:

Hi @bobi33,

It's a virtual path to an API endpoint, so you won't find any physical files.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[kjac]

If you're certain it's the IP restrictions that are causing the problem and you can't lift them for the route mentioned above, you have two options that I can think of right now.

You could reimplement the form editor endpoint in a controller that's not routed under /umbraco, and adjust the script accordingly.

You could swap the async rendering with the noscript one.

I'd probably go with the latter option.

Den 1. mar. 2018 2.34 PM skrev "bobi33" notifications@github.com:

Ah, ok.

So what do you think is the best way to resolve this? It’s clear that IIS IP blocking causes this. I don’t know if I can provide access to a certain file in the /Umbraco folder to fix this.

I’m lost :s

On Mar 1, 2018, at 01:58, Kenn Jacobsen notifications@github.com wrote:

Hi @bobi33,

It's a virtual path to an API endpoint, so you won't find any physical files.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kjac/FormEditor/issues/177#issuecomment-369592787, or mute the thread https://github.com/notifications/unsubscribe-auth/AHD_CiJjhIK7aSnIgtR4j1zpDS4qS0b6ks5tZ_j9gaJpZM4SWFjT .

[bobi33]

I’ll try the latter option, but I’ll wait for the updated nuget. I wish it was as easy as finding the route in Umbraco, but perhaps I can’t see it because I have an older version.

By updating the nuget version would it rewrite all customized forms and code that I’ve added?

Thanks for all of your help Kenn! You’ve always been awesome.

On Mar 1, 2018, at 09:12, Kenn Jacobsen notifications@github.com wrote:

If you're certain it's the IP restrictions that are causing the problem and you can't lift them for the route mentioned above, you have two options that I can think of right now.

You could reimplement the form editor endpoint in a controller that's not routed under /umbraco, and adjust the script accordingly.

You could swap the async rendering with the noscript one.

I'd probably go with the latter option.

Den 1. mar. 2018 2.34 PM skrev "bobi33" notifications@github.com:

Ah, ok.

So what do you think is the best way to resolve this? It’s clear that IIS IP blocking causes this. I don’t know if I can provide access to a certain file in the /Umbraco folder to fix this.

I’m lost :s

On Mar 1, 2018, at 01:58, Kenn Jacobsen notifications@github.com wrote:

Hi @bobi33,

It's a virtual path to an API endpoint, so you won't find any physical files.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/kjac/FormEditor/issues/177#issuecomment-369592787, or mute the thread https://github.com/notifications/unsubscribe-auth/AHD_CiJjhIK7aSnIgtR4j1zpDS4qS0b6ks5tZ_j9gaJpZM4SWFjT .

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[kjac]

@bobi33 you're welcome :)

There's no new release planned at the moment; the updates I was referring to earlier were for the code samples section.

If you update the NuGet package, chances are you'll be prompted to overwrite any files that you have changed. I'd always recommend you doing so and using your source control diff tool to figure out if you need to merge new features into your changed views (though I always to my best to be backwards compatible).

[bobi33]

@kjac thanks! So there is no folder in /umbraco that can just have an "allow" status under IIS IP Domain allowing/blocking? Haha. That would be so much easier. I guess I can change from async to noscript rendering , but I always thought async was more secure, and quicker for loading.

I wonder if this is an issue because I have not updated the nuget...hmm.

[kjac]

@bobi33 /umbraco/FormEditorApi/Public/SubmitEntry/ is not a physical folder on disk, no. It's an endpoint in an API controller. However, all requests to it behave as if it was a folder on disk, at least from a core IIS perspective. Perhaps you can lift the IP blocking for that specific path without having to point out an actual folder on the disk?

Asynchronous form submission isn't anymore (or less) secure than the synchronous form submission. It all boils down to user experience, really.

[bobi33]

Hmm...I'm thinking about how to lift the IP blocking for that specific path in the web.config...especially if it is not a physical folder.

Re the async vs sync ... so sync may not create the same issue? Or no script for that matter...I should try that out then, instead of getting too "Fancy" with fixes...simplest solutions are always the best :)

Again, you rock!

[kjac]

I'm closing this now, feel free to reopen if there are any further questions to it.

[bobi33]

Hey @kjac, I just got around to making the simple edit from Async to Sync, and Sync works with the IP address blocking.

Thanks again for the simple solution. :)

Stay awesome.

[kjac]

@bobi33 I'm glad you worked it out 😄

[bobi33]

I am using an smtp service (SendGrid) for the notifications. However, after adding the SendGrid SMTP mail service, it appears that the form page now loads quite slowly after the form is submitted. Any ideas on how to speed this up?

You can check out the slow speed here: https://slclaw.ca/contact-us

Before adding the SMTP service (without email notifications), the form did not submit that slowly...only now after adding it. I am using just SMTP Service (not any API).

[kjac]

@bobi33 I don't usually see any performance issues with notification emails; all emails are sent asynchronously (see the code here). I've never used SendGrid SMTP though, but testing with similar services (i.e. Mailtrap) has never proven problematic.

[bobi33]

@kjac Hmm...Very strange. I wonder what's going on. Async and Sync work fine without configuring the SMTP datatype. I know that the SendGrid SMTP doesn't delay things when I use another email function of umbraco (eg. forgot password). Also, to troubleshoot, I removed the SendGrid SMTP in formeditor - the form worked perfectly (acceptable quick), both using Sync and Async.

I'm baffled. SendGrid SMTP works perfectly fine with other notifications (i.e. Umbraco password reset); FormEditor works perfectly fine without setting up the SMTP SendGrid; but form submission takes forever as soon as I add the SMTP SendGrid info.

As part of the troubleshooting, I also tried Mailtrap SMTP...same issue. I'm so confused.

[kjac]

Hi @bobi33,

I've just tested email notifications for good measure. Below is a gif with the actual performance of the emails (using the sample email template). As you can see it's pretty much instant, and the email is received moments later in Mailtrap. And that's running on my (none too fancy) laptop that simultaneously runs Visual Studio and a bunch of other programs.

Could it be that your email template is doing a lot of time consuming work - DB loading, content querying, ...? The template is rendered synchronously, it's only the SMTP connection that's offloaded into a new thread.

[bobi33]

Hi @kjac,

This is so strange. I am also using the sample email template (even more simple than that...just an h2 indicating "New Notification"). I see that yours is pretty much instantaneous. I am running it off of a VPS. I first thought that I set up umbraco email notifications incorrectly, but it works quickly with the "forgot password" in the back office.

I added some styling into the .cshtml files to make the checkbox, textarea, etc. match the formatting of the website. I wonder if that's playing a role in the slow speed.

I'm baffled.