So first the user submit a form and will appear a new window in which you have a 5 step page
my aim is to create one submission procedure multi step form in which user can upload a file & etc..........
And so on.
It's much like an state-machine,
Don't know if my design is bad or if there's some correct way to do this?
Thanks.
I prefer using Jquery to handle this (via hiding and showing divs after various steps), that way there is one easy form with the multiple steps.
Server side multi step forms, afaik, are not available with Rails as they do not gel well with the whole RESTful architecture.
However you can create a key-value data store (memcache, flat file or a table) which has a key and stores data as value at each step in a hash. Keep pushing the data back to the server after each step and storing it in this hash. To go back to previous steps, you can devise the URL of the form as ///. Key can be a UUID.
Related
We need to develop an API which takes a CSV file as an input and persists them in database. Using vertical slicing we have split the reuirement into 2 stories
First story has partial implementation with no data validation
Second story completes the usecase by adding all validations.
Sprint-1 has first story and sprint-2 has second. After imlemneting first story in sprint-1 we want to release it to production. However, we dont want to make the API accessible to public which would be big security risk as invalid data could be inserted into database (story1 ignores validation)
What is the best strategy to release story1 at the end of sprint1 while addressing such security concerns?
We tried disbling the access via toggle flag such as ConfigCat. However, we dont want to implment something which is not required for actual implementation
is there really such a risk that in 1 sprint, someone may start using the API? And if you haven't added it to any documentation, how would they know of it's existance?
But let's say it is possible - what about using a feature toggle? When the toggle is activated, the end point spits out null or even a HTTP error code. Then you can enable to feature toggle when you're ready for people to start using the endpoint.
How to refresh the interface after you add a strip of data to the backend database in Vue.js?
I mean, if I add a item data to the database. there are two case for refresh the interface.
refresh the list api to get the page data.
append the added item data to local list.
what is the best way to do this?
I think both the solutions are valid it depends on what kind of write operation we are planning to do. Given that you do all the validations on the front-end which leaves lesser chance for errors on the backend. I do the following based on the use case.
Add/Update the item locally and then based on the response from the server I remove it again in case of an error. This is an optimistic technique used by a lot of websites and worls really well for CRUD kind of operations.
Let's say that your new operating is going to creaate a new user in a 3rd party api. So doing an optimistic thing might not be the best. So what I do is make the request, show a toast/alert that the request is happening, and then use sockets or long polling to get the changes. When the request is finally done show the data. In the meanwhile you can insert a dummy item showing loading.
I am making an API wherein I want to dynamically get data from the site http://transportformumbai.com/mumbai_local_train.php
Depending on start and end station and timings I want to get the list of all available trains along with the table given by clicking on viewroute column table. i.e. for eg.
I am using import.io connector... But it works well with a single textbox but not with multiple textboxes (Refer this link)or dropdown lists...
Can anyone guide what should I do next...
Apart from import.io is there anyother alternative?
I am a newbie working with crawlers... So please justify your answer.
What is web scraping... Do I have to use web scraper??
Thank you.
Actually, if you look in the URL bar the parameters for destination and time are defined there (highlighted below), so you don't need to worry about drop down menus, or using a Connector.
Use an Extractor on this page:
http://transportformumbai.com/get_schedule_new.php?user_route=western&start_station=khar_road&end_station=malad&start_time=00&end_time=18
Train it to get every column - note that the view route column contains links.
You can create a separate Extractor for the "view route" page:
http://transportformumbai.com/view_route_new.php?trainno=BYR1097&user_route=western&train_origin=Churchgate&train_end=Bhayandar&train_speed=S
Now you should "Chain" the second Extractor to the first one and it will pull that information from every link on the first one.
If you want to choose different destinations and times, just change the URL parameters of the original link.
http://support.import.io/knowledgebase/articles/613374-how-do-i-get-data-behind-dropdown-menus
Your best bet here seems to have an API for every URL combination. You have to analyze the URL structure.
I'm having a bit of a trouble understanding how to fit a particular design flow I have into a proper REST architecture. Let me explain the flow:
I'm creating technical support website where users can submit ProblemRequests. On the front page, the user selects all the categories he's having trouble with and clicks "get help," which then redirects him to the next page where he fills out some forms to submit his request. Here are the pages:
Page 1 - Select Problem Categories
Page 2 - Fill out Problem Request
Page 2 basically acts like the NEW action for a ProblemRequest. The thing is each ProblemRequest depends on multiple ProblemCategories, so a nested route isn't going to work here. The next thing that comes to mind is sending in all relevant ProblemCategories ids as an GET param for the NEW ProblemRequest action, but I would rather not expose the IDs in the URL.
A Multi-Part form sort of comes to mind, but that involves making ProblemRequests have state, where some would be complete and others incomplete. I don't want to deal with the implications, because in reality this is a one page submission, not a very long-winded process.
What would work ideally is to override the NEW action for the ProblemRequests controller to respond to POST operations, but I don't know if this is considered bad programming practice. Is this a cardinal sin? Is it okay for me to change the NEW action to respond to POST instead of GET?
Please advise,
Thanks in advance.
Keep it simple. Is there any reason for the round-trip to the server? I'd just make the two "pages" a single page and maintain the state of the selected categories client-side.
Use a multi-step form: http://railscasts.com/episodes/217-multistep-forms
You can save the IDs in the session, and the model won't get saved in the DB until you are finished filling out the info. Works great for simple 2 or 3 step forms.
For more complex wizards you could use a gem like https://github.com/schneems/wicked
I'm using the following security(invisble captcha) for my site's form submission to prevent auto submission:
generate the result of md5 with a fixed salt on number x and render it
inside the form as a hidden field
generate 2 hidden fields a and b where a + b = x, a and b are
unencrypted
upon submission, use javascript to add another plain hidden field c
where c=a+b
on server side apply md5 on c with the salt, compare it with encrypted
x
However such system is cracked in production, one person was able to auto-submit thousands of forms successfully. Any idea how?
One way to do it is, the hacker already knows that the operation is + (simple to find out by observation of javascript), read the form and add a and b, create a new form with the extra c field where c=a+b. He has to first read a form, then create one for submission.
My questions are:
Is the hypothesis I presented above the likely way to break my system?
If so, what should I do to prevent this kind of hack?
What are other alternative hacks the hacker might use?
I don't want to use real captcha because it degrades user experience. All suggestions are welcome.
Alternatively, the hacker could just execute your javascript themselves.
If you want to validate that the user isn't a robot, you'll have to get the user to do something a robot can't. It's really that simple.
A further step would be to increase the amount of computation required; make it infeasible to submit the forms too rapidly. Try looking at HashCash.
I can't give advice in your specific case, but Django has some nice approaches, how spam in comment fields could be supressed without captchas: Nice approaches here.
Your system is not working because the attacker(s) are just executing your JavaScript themselves. If you want to use a somewhat similar scheme that will prevent automated submissions you need to put a workload factor on the client. This will not stop the automated software from being able to submit to your site but it will slow them down and increase the cost of an attack. The goal is to increase the cost and slow them down enough that the attack is just not worthwhile. Instead of trying to build it yourself try using this proof of work service.