I want to set up a page within my site that contains a form for a prospective client to fill.
I would then manually inspect the form's results to ensure the prospect is qualified, and then send them a temporary link to another page that expires in a few hours, or perhaps after one click.
Any advice that can help me towards this goal would result in me thinking you were very cool.
Thanks!!
ms
This would be done server side. The general flow would be that you would submit the html form to the server. Place the data from the form into a server side database. Send an email to the site admin, notifying them that an entry has been made. Then build a control panel where they can view entries and approve them. This would then send an email to the form submitter, grant them access etc.
It may be an easier better approach to use a form service that does most of this for you.
Take a look at:
https://www.formstack.com
If you want to code it your self. You could use a framework such as:
https://firebase.google.com/ (Js)
or
https://github.com/expressjs/express (Node js)
Related
I'm working on a payment system with React-Native. I want to do research on how to apply 3D payment methods. I want to listen to an event happening on my server on the client side. actually i only need this for the following reason. I feel there is something I got wrong here.
3D Secure Steps
I send the product to be purchased to a service named iyzico with
credit card information.
If the information entered is correct, it gives me an answer as below.
There is a special field here and I need to decrypto it and show it to the user.
In fact, this crypoto information contains an html page.
By decoding this code, I show the user an html page.
The password sent to the user's phone via SMS is entered on that
screen and presses the confirmation button.
The part I don't understand starts here. The person is in a true asynchronous. I want to callback. Because he can enter or cancel the password sent by SMS whenever he wants.
I'm not wondering how the process turned out. How will we inform the client application only in this case?
Should we use push notifications or other push services for this?
The client has to get information about this process. According to the information he receives, I would like to suggest that your payment is successful or your balance is insufficient.
I know that I should avoid making circular calls.
In short, how should I listen to the client for an event that will take place on my server? Which would be the best method?
I am working on React-native and I do not want to include push services in the application just for this. It is costly for me to this. I believe it is a more beautiful solution.
What do you think about this subject?
Thanks.
You either need push notifications or long polling. https://ably.com/blog/websockets-vs-long-polling
The Film-Production Software Shotgun offers a web interface.
To write notes, coordinator often have to fill in the same information into the forms, because there is no easy way to pre-fill the form automatically based on a project or page.
How can you prefill an autogenerated form, where you do not have access to the sourcecode of the website, which you would like to alter as a client automaticlly.
This is not trying to achieve, to alter the whole website on the web, rather just trying to alther the users html to improve the speed and remove redundant form entries.
Thanks
It would be possible to store this data in the cookies, although I do not know which implications this would have security wise. Ofcourse this would be much easier if there was a way to store this data server sided and collected from there.
Try creating a dictionary or JSON object based on the form, and store this data in the cookies. collect the data from the cookies if the user lands on the form again. The benefit from this is that you could implement this without ever actually handling the data, and being able to base it on a session so the cookies get cleared once a user drops the page.
We have a form, if a person fills that form, we are hitting POST API.
When user submits the form, complete INFO of API (request url, headers) is visible, I was thinking if someone starts hitting this POST API through server side code, our tables would be filled with junk values?
How can we avoid this bulk data entering the system through API being directly hit by C# client, POSTMAN or any other server side clients?
That's a really open ended question, but I don't think there's a way to do exactly what you ask (detect with certainty if a request originates from a browser or not), nor should you if it were possible - users may have a legitimate reason to use something other than a browser, or someone might want to integrate your API into a larger process, etc.
You should handle this via authentication - require the user to be authenticated with your API, then if they misbehave you can disable their user accounts (either manually or automatically with some sort of abuse detection).
There are times when authentication is not possible or desirable for a web form. At those times a I have used a key generated on the server that I embed in the form.
The form sends back the key along with the rest of the data and you can then make any decisions you need to make based on the key. Like limiting the rate of submissions, allowing only one submission and then expiring the key, etc...
Use a captcha: a challenge is presented to the user to prove being a human, usually an image that contains some garbled text is shown to the person filling the form and (s)he is required to transcribe the text content of the image in the form. If the captcha solution is wrong or missing that POST request to the API will be discarded.
Many types of challenges are commonly used such as audio/visual/logic/mini-puzzles. You can also customize your challenge in a way that fits best with your form. For example Google provides ReCaptcha, a captcha service with js and server api.
This helps you prevent or mitigate bots, as the captcha is a challenge that is very hard for computers but easy for humans.
Using one-time captcha tokens also prevents the replay attacks you are worried about. Also, checking that the ip that received the challenge and the ip resolving it are same helps mitigate other tricks.
This still leaves room for a determined human to spam your form. So you should also keep track of the number of submissions and throttle them by ip.
A site I am working on requires user information to be collected from a form when the user presses the submit button. The site will then take the information and plug it into a more robust form on a different page, so the user does not have to retype the information twice.
Is this possible using javascript?
Any help appreciated.
Once the user leaves the current page, the JavaScript on the original page is no longer running, They will load up the other page and run that page's JavaScript.
Do you have ownership of both pages?
If so, then you can leverage the form GET to pass information across pages, so the next page will have a Query string, and JavaScript can parse that.
Another way to move data from one page to another is to use Cookies. So it really depends on how much data you want to move around.
But I highly recommend that you leverage the server-side technology to handle the form GET or POST and carry information across pages.
This completely depends on the OTHER site. You can have a form with the same field names and post it to the same URL the other site's form uses.
BUT - if that site checks to see where the original post came from, it may block you out.
on a site the user can enter an email account to gain access. do not want this to be hacked by script kitties.
the input items are generated by javascript and posted via ajax. do I need things like fuzzy word matches in this environment?
Any time you give some user the possibility to input something, every time your application expects some data from the users, those data can be forged.
No matter how your form is built : your webserver espects some data ; those form and data can be forged/faked ; so, you must be prepared for anything that could be sent to your application.
Still, you can add some levels of security, using, for example :
HTTPS so communications cannot be listened to
A nonce in your form, to make things harder when it comes to forging forms
I assume you mean adequate security against someone writing a script to fish for for valid e-mails using a brute-force style attack? If so then no, your presumption that "script kiddies" are incapable of either scripting a full-fledged browser instance that can execute your JavaScript content or determining what URL your AJAX ultimately submits to and then forging requests is false.
If you want to protect against these kinds of attacks, then the only effective way to do so is to add code on the server side. For instance, you could track the number of incorrect access attempts posted per IP address, and block requests (for like an hour or so) from any IP that posts more than, say, 10 invalid requests in a 5-minute time span. Then you are reasonably safe against this kind of attack until you come across someone with a million-IP bot-net and a grudge against your site.
Another form of protection is to send some random code from the server to the client that gets submitted back with the form (for instance, as a hidden field), and code the server so that ignores any form submits that do not include this code. This solution works best if you have some way of verifying that the user is trustworthy before you display the form (so it's not really useful in the context of a login form, but it could help secure any post-login forms that you may have). Otherwise it is not too hard for an attacker to compose a script that just grabs a code from your server, and includes it in a forged request.
JavaScript + Ajax forms are just a more fancy means of forms. It's still a request with post/get data so same security measures should be undertaken as per normal HTML form.
Wether you use Ajax or basic HTTP requests, don't send back data you don't want users to see either way. Don't offer services or functionality by means of JavaScript/Ajax you wouldn't offer by means of basic HTTP requests.
Script injection does not need an JavaScript/Ajax vulnerabilities, it just needs unsecure backend code that doesn't catch and eliminate code injections.