Posting data as multipart/form-data the MVVC/AngularJS way - javascript

I am developing a webapp using AngularJS for the frontend (still very new to JS) and Go for the backend and I am stumped trying to POST multipart/form-data encoded data instead of URL encoded. I have tried to google it, but I cannot seem to find an example that doesn't assume that I'm only trying to upload a file. I am simply trying to POST a simple form with some text fields and no files.
I can get it work by bypassing Angular with a simple html form using method="POST", but it is surprisingly difficult to do in javascript.
On the server side, I am decoding the POST request with http.Request.FormValue("key").
Could someone point me in the right direction? Cheers!

There is always the posibility to invoke the submit() of the form element (using jQuery here):
$('#yourForm').submit();
This will (of course) require that the endpoint targeted by the form handle the "full browser rollby" - and redirect properly.
It might be a better solution (since you control both frontend and backend) to have the Angular application submit JSON (as it defaults) and just handle that on the backend.

Related

How to connect dynamic HTML to MySQL

First, I'd like to say this is part of a university undergrad project, so my knowledge will be limited.
I have a MySQL database set up with data and I want to click a button in HTML that queries the database and updates HTML table elements with returned data. I have done A LOT of reading and it always returns to nodejs which I have absolute beginner experience with. I have code set up to query my database with nodeJS which works fine, however, I see absolutely no solution to update the HTML dynamically and I refuse to believe it is not in some way possible. I have read about expressJS templating but this dynamic updating of data is expected to occur hourly from the database (the database is a dummy stand-in for a real-life one) and the expressJS templates are not a good fit at all.
How can I return nodeJS data to a HTML page without serving a new page each time? perhaps return server-side JS data to client-side JS? how does nodeJS allow the HTML to then load client-side JS files? I am unable to get a PHP install working so it's unfortunately not an option. I am open to any alternatives that allows HTML to MySQL connections.
Thanks
I'm not 100% sure what you have set up or what your level of knowledge is, but I hope I can help.
Sounds like you have your server running and querying your DB just fine, so that's good. Now you need to route that to your frontend. This is where expressJS usually comes in. It's a backend framework for creating API's in node. Think of it as a middleman. You send a request to your API, and your API makes a request to the DB and gives you what you want.
To make the request from the frontend, you can use the fetch() API. It's an asynchronous function used to make https requests and receive data. You then need to use that data to dynamically populate your html. Since it's done with javascript, it won't force a reload of the page either.
Feel free to ask questions and hopefully we can get you pointed in the right direction at the very least.

How to retrieve the URL to which the request is sent when the form submit button is clicked??

I am using this web-app - 'http://podaac-uat.jpl.nasa.gov/mcc/' and I want to know the url of the server to which the request is sent to when I am hitting the submit button. I am writing an API that needs to send the request directly to the server with the required parameters set rather than using the web-app.
Thanks for the help in advance. :)
If I understood correctly what you are trying to do, one way to find out what the Compliance Checker is trying to do is to capture the traffic when submitting. This can be done using various tools such as Fiddler, but all modern browsers allow this.
As a test, I have used Google Chrome to check the request made by that submit form:
POST request includes uploaded data in its body. However, it is very likely that the site will not allow POST calls from another domain (i.e. your application) - see here and here for references.

Risk in returning HTML content on AJAX call via HTTPS

I wanted to load HTML contents dynamically, such as updating a Bootstrap's modal dialog contents via AJAX call (because refreshing the page and showing the modal again is weird), but before I do that, I want to know what risks that I will need to concern when doing so, and possible solutions.
The main reason to do this is that I'm developing a portlet for Liferay, and I wished to update the content of my portlet dynamically without refreshing the whole page.
Of course I could return data in JSON from my server to client, but I will have to write complex client side logic to update the DOM, which the logic is probably done easier in, say, JSP
Assume the webapp is HTTPS only, not sure if this will help with anything.
Based on the assumption that the webapp is HTTPS only, it would be very good to let all AJAX calls also use that. This will not create a breach of mixing unsecure and secure connections, and the warning dialogs, which browsers give.
The only risk can be caused by cross-site scripting, if parts of the HTML is generated elsewhere or if parts of it is based on unvalidated user input.
Solutions for that is to always validate ans sanitize the input from other sources. More information about this can be found here: https://www.owasp.org/index.php/Data_Validation
Perhaps you chosen the wrong framework for the job and would have consider something like an client side rendering where you would bind json data to the view (eg: angular, ember, backbone or knockout)
Consider using Element.innerText or $(Elm).text() instead of Element.innerHTML or $(elm).html() when possible
Perhaps it will be a good idea to encode everything that a user can change before you save it to the database or when you are rendering the view
However if you do allow some html you would need a sanitize plugin with a witelist approtch to strict the allowed tag & attributes
the only diffrence with http and https is that it will be much harder for a man-in-the-middle attack to read/intercept/change the content of the request & the response

Clientside URL Routing

Looking at turning my ASP MVC app into pure JS/Html however its not just a 1 page app, it has a couple of pages, but each one has alot of ajax and events.
Anyway currently my urls on ASP MVC are like:
/login
/admin/{action}/{adminId}
/posts/{posterId}
/picture/{pictureId}
So that is all nice and simple and easy to see what you are doing in the url, you also get correct back button behaviour. So trying to adopt this sort of thing to a pure JS/Html approach seems to bit either very tough or impossible. I dont need an exact match but I was hoping to do something like:
http://localhost/myapp/posts/10
Then that would somehow be able to route the actual request to http://localhost/myapp/posts.html with the variable exposed. Now I am pretty sure this is impossible as when the above is entered into the browser it is going to attempt to look in a directory called posts and look for 10, which wont exist.
Now I have seen Crossroads and LeviRoutes and a few other similar technologies, however they seem to rely upon the hashbang method, which some people like others hate. Is there any way around this? If not can anyone point to any good tutorials on how to use these frameworks, as each seems fairly light on documentation.
There's no workaround for not using hash. HTML5 History API isn't available on IE and Opera yet. If your application is targeting very specific platform, then you can use History API instead of hash. However, History API is inconsistent across browsers. You can read it here: http://www.battlehorse.net/page/2011/02/12/html5history.htm
If you choose to use History API, it would be easy. You can use whatever routing strategy you want in ASP.NET MVC, then just match this strategy in JavaScript. You can read more about History API here: https://developer.mozilla.org/en/DOM/Manipulating_the_browser_history
If you choose to use hash, you need to do make some requests into AJAX requests:
Determine if a request is done via AJAX:
if GET/posts/{action}/{id} is by AJAX, serve the original content
if it's not by AJAX, redirect the user to /#!/posts/{action}/{id}.
Handle client side hash by requesting for the right content:
When the hash is changed to #!/posts/{action}/{id}, GET /posts/{action}/{id} via AJAX and replace the content with the new one from the server.
Intercept form.onsubmit event:
Whenever a form is trying to submit to /posts/{action}/{id}, cancel it and use AJAX to post and then replace the content with the new one from the server.
Now your app should work like a one page app.
There is no real way around hashbangs if you wish to keep it clientside and cross browser compatible.

Best way to return a user-generated file, AJAX or Forms?

I'm new to web programming, so I need some help.
I am writing a custom file-creation app for my site. A user visits the page, clicks on some various options and toggles some checkboxes, and the presses a 'download now' link.
I have a PHP backend which will be processing the submission, and generating a PDF file. After the user presses the download link, I want the download to start like it would for any static link.
My question is: What is the best way to do this? From my limited understanding, I have a choice between using AJAX or somehow using forms to submit the data. What are the advantages/disadvantages of each? Does anyone have any good links to examples?
Thanks
Actually you cannot download a pdf via XMLHttpRequest (AJAX).
In general you should simply redirect the user to the resource that will generate the PDF with the proper MIME type, and then leave it up to the browser to figure out how to handle it.
AJAX will not work here, because you cannot use AJAX to download the file.
Instead, you should make a normal form, and have the PHP backend serve a file download when the form is submitted.
Just use a form. Ajax provides no benefits and a lot of complications under these circumstances. (You could use it, although you would have to use a non-XHR implementation, but it would be pointless to do so)

Categories