Contact Page looks awful

[reesericci]

The contact form page has no styling and is an iFrame of a 3rd-party service. It should be set up where the form is hosted on the JB site with all the JB styling and then submits the results with the action parameter to a 3rd-party API which processes the form and sends an email or whatever.

[reesericci]

Why does the upload an image field exist if nobody is supposed to use it?

[reesericci]

https://bulma.io/documentation/form/general/

[gerbrent]

I love the frankness of this issue title ; )

[reesericci]

Imo this is important for the 1.0 milestone to properly create a consistent contact form.

[reesericci]

I'd be willing to work on it if I know what API I'm tying into.

[ErraticKnight]

I'm guessing that would explain the weird behavior I saw yesterday there. If you drag the comment box's resizing corner you can pull far enough down to push the UI that lives below underneath the footer; if you pull enough you can get the hot zone for the resize corner pulled underneath the footer as well which makes the change unfixable.

[elreydetoda]

Related to #139, the original plan that @kbondarev and I chatted about over there was to just have an API on the backend the form is submitted to. (so everything is self hosted)

We stopped pursuing that, because we had (at the time) though that the old contact form would be enough for the 1.0 release. Then we could do the re-write possibly for 2.0.

We're still only at 50% and there is still plenty to do, is there a critical reason why the 1.0 can't just re-use the old one? Since this is mainly an MVP (or Minimum Viable Product) for the 1.0 release, as long as people can still properly write in and submit feedback then IMO I think this could be put back to 2.0. ( trust me I know I'd love to add a bunch of things as well 😅)

The other thing to take into consideration is that if we change this, we might change the internal JB workflow. Which is probably a good thing to make it easier for them, than just consuming emails from a 3rd party. I think if we take our time on this and do it right, then we could make it really nice and easy for the JB team to get feedback. Making that all work for them by the launch deadline though, doesn't seem easily feasible (without it being someone dedicated to coordinate everything I mentioned above).

(Just my 2 cents)

[elreydetoda]

Why does the upload an image field exist if nobody is supposed to use it?

I'd imagine it's probably a storage or space requirement, because depending on the provider they might only get images depending on their size. (Completely hypothesizing)

[elreydetoda]

I'm guessing that would explain the weird behavior I saw yesterday there. If you drag the comment box's resizing corner you can pull far enough down to push the UI that lives below underneath the footer; if you pull enough you can get the hot zone for the resize corner pulled underneath the footer as well which makes the change unfixable.

I wonder (as a temporary fix) if we make the iframe scrollable (I think we can do that) then it would allow you to still access it?

Thanks for the heads up and good testing @ErraticKnight! 😁

[reesericci]

But if we make the iFrame scrollable, then everyone has to look at an ugly scrollbar - which they wouldn't need to use unless on rare occasions.

[elreydetoda]

Ya, that's a fair point. Also, looks like the current JB website has the same issue. So, honestly we probably should just leave it.

I hate saying that, but you can actually scroll inside the box if you don't drag it at all as well. So, I think just leaving it as is would be the easiest solution currently.

[gerbrent]

Related to #139, the original plan that @kbondarev and I chatted about over there was to just have an API on the backend the form is submitted to. (so everything is self hosted)

We stopped pursuing that, because we had (at the time) though that the old contact form would be enough for the 1.0 release. Then we could do the re-write possibly for 2.0.

We're still only at 50% and there is still plenty to do, is there a critical reason why the 1.0 can't just re-use the old one? Since this is mainly an MVP (or Minimum Viable Product) for the 1.0 release, as long as people can still properly write in and submit feedback then IMO I think this could be put back to 2.0. ( trust me I know I'd love to add a bunch of things as well sweat_smile)

The other thing to take into consideration is that if we change this, we might change the internal JB workflow. Which is probably a good thing to make it easier for them, than just consuming emails from a 3rd party. I think if we take our time on this and do it right, then we could make it really nice and easy for the JB team to get feedback. Making that all work for them by the launch deadline though, doesn't seem easily feasible (without it being someone dedicated to coordinate everything I mentioned above).

(Just my 2 cents)

@elreydetoda - all of this is perfect spot on for how we're approaching the project currently - imprelement essentials first, then the nice-to-haves after our Milestone 1 publish date. Your considerations of JB's internal workflows is also super appreciated, since we certainly want to reduce the number of changes to our everyday workflow, especially considering we will be going into the JB Road Trip to JPL crunch time just about when this all gets up and running. So, all that to say: We really, really appreciate your perspective here. ❤️

[gerbrent]

I'd be willing to work on it if I know what API I'm tying into.

@reesericci - aware this somehow didn't get mentioned here. Whoopsie.

API to target is Wufoo: https://wufoo.github.io/docs/#form-fields

reference: https://jblive.wufoo.com/embed/w7x2r7/

[reesericci]

I'll get to work writing up a quick form that ties into wufoo!

[reesericci]

I won't be able to work on this for a little while - I'll relinquish my assigned status for now.

[elreydetoda]

Thanks for keeping us updated @reesericci and letting us know when you don't have time to do something. 🚀

It's hard to keep track of that and keep boundaries for things you enjoy, so thank you for letting us know 😁🚀

[elreydetoda]

I think this could be moved to 2.0, unless someone has time to work on it for 1.0. We already have a form, yes it doesn't look the best but it'll be replaced eventually anyways (for something a bit nicer).

[CGBassPlayer]

I think I will take a crack at trying this since I have #485 (which is the second time the iframe failed us). I'll steal all the info in this issue and see what I can come up with. I am still lacking in free time so I won't promise anything, but I really want to revive this

[reclaimingmytime]

I looked into this a few months ago. I remember that you need to be careful not to expose the Wufoo API Key in the frontend. So, just making a web request via JavaScript would not be an option with the API.

From the docs (https://help.wufoo.com/articles/en_US/kb/Wufoo-REST-API-V3):

You'll need your API key to use the Wufoo API. Your API key is unique to your account and grants access to your data, so make sure to keep it protected the same way you'd protect your password.

Because we're using Hugo, we can't just put the logic in the backend like in other web frameworks. The alternative could be some server-side code which would require more maintenance, or using an entirely new API.

[CGBassPlayer]

Another option would be to create an environment file that contains the API key and is only on the VPS and passed through to the Docker compose? I haven't looked too into this too much but I would imagine there must be some way to get it in vanilla JS. I'll be looking into this idea shortly

[reclaimingmytime]

I believe the environment file would only prevent people to view the API key in the repo.

If the API request to Wufoo is done on the client-side, the API key must reach the user's browser somehow, allowing them to see it. Even when the API key is encrypted and decrypted to make it harder to view in the source code, the user can just use the network tab of their browser and see the API key in the request made to Wufoo.com.

Just my thoughts on this. Maybe there's something I'm missing.

[CGBassPlayer]

So crazy thought to throw out here...

What if we did a super small FastAPI app acting as a sort of proxy in its own docker container that can manage things like this? Set up an endpoint that basically just forwards the JSON body and that adds the API key. Then the client side would see the request to the backend and hides the secrets.

An approach like this would add minimal resources to the production deployment as a basic python-uvicorn style container could be pretty small.

How far off base does something like this sound? I know it is not ideal with a static website, but I think it would be wayyy better than the iframe of the form we currently have. Probably would be its own repo as well

[reclaimingmytime]

That could work. We wouldn't be exposing the API key to the client.

On a related note, I just found out that Wufoo might directly support what we're trying to do here.

I created a Wufoo account and a dummy contact form when I was looking into this a few months ago. On the "API Information", I see the following:

POSTing From Your Site
In some cases, you may want to embed markup straight into your site (not in an iframe), but at the same time you do not want to learn our API. We do allow you to do this, but there are a few things to consider. We outline the details in our POST documentation. In addition to the docs, you will need the POST key below to get started.

Your POST Key: [key]

"POST documentation" links to "nameofcontactform.wufoo.com/docs/api/", which redirects to https://help.wufoo.com/articles/en_US/kb/Wufoo-REST-API-V3. I can't find any info about a "POST key" on the documentation, so maybe this feature is no longer supported.

The only public mention of "POST key" on Wufoo.com is in this blog post: https://www.wufoo.com/blog/sweet-code-manager-upgrades/

Now, when you use our HTML/CSS code export, your forms include all the appropriate markup changes to make it so it can just submit straight to Wufoo’s servers without having to find the action URL or grab your API POST key. Just download the zip file with our markup and it’ll be able to submit straight to Wufoo’s servers right from the get go.

So maybe we can just export the HTML from Wufoo and work with that? Maybe copying the HTML from the current iframe at https://jblive.wufoo.com/embed/w7x2r7/ (with form, action, etc.) would bring the same result? If we have access to the HTML, we would have full control over the style.

---

Edit: Turns out that we can't just copy the HTML from the iframe, because a hidden input field with the id "idstamp" always gets a new random value. When I exported a form as HTML, the "POST key" is in there, so that's where the key is used. Seems like a weird way to get around some CSRF protection to me.

The question is still if we want to go with the Wufoo way of using a "POST key" and an exported form, or your suggestion of a separate backend.

[reesericci]

I think having a FastAPI endpoint is a bit overkill - a serverless edge function from the likes of Cloudflare or Deno would be much easier to get up and running and do the same thing.

[CGBassPlayer]

I was only thinking FastAPI to go along with our python testing and have something we could have grow with us as the website adds more and more. Definitely not against using Cloudflare though.

[CGBassPlayer]

I have a couple ideas on how to clean up this contact form. I have already started prepping the new contact form on the front end, but I need to start looking at the backend of this form and getting it to Wufoo.

What would the feasibility of of hosting an additional container to call the Wufoo API. I am thinking the something along the lines of:

1. User enters feedback on form built on the website
2. When the user submits the data, it calls out to this API container with the data from the form
3. The API takes the data and calls Wufoo with the credentials and submits the form.

My other idea was getting that idstamp from a wufoo form. @reclaimingmytime had mentioned that this randomly generated string was hidden in the form. I am thinking we could add some JS that when the user loads the contact page, it would call the wufoo form, extract that idstamp field. Something like this:

1. User loads contact page
2. JB site calls out to the wufoo form and extracts the idstamp from the html
3. When the user submits the data, we call the same submit function the wufoo form does with the retrieved idstamp

To me the better idea seems like the separate container for the API. My hesitation to this though is then we are introducing a backend to static website. But I am curious to know what others think about these ideas.

[reclaimingmytime]

The frontend looks great so far. I'm sure the native form would also improve loading times compared to the current external iframe.

I prefer a solution without another backend. Your first option secures the key from the client, but the key still needs to be stored somewhere. I'm sure it can be secured easily with a proper backend so the key is not available to the client, but it is still something we need to worry about. It would be better if we wouldn't have to worry about storing sensitive API keys at all. Also, this would be another external service that someone needs to maintain.

I like the second idea of fetching the idstamp field via JavaScript. I tried that with a different Wufoo form, and that seems to work. I thought cross-origin would be an issue because of the different domains, but wufoo.com has the Access-Control-Allow-Origin header set to *.