Ecto Changeset and Form validation and update using PUT

I think people will see clearlier your code if you use the forum code formater (Ctrl+Shift+C on selected text).

In my humble opinion, your code would gain also a lot of readability if you use Phoenix contexts. If you don’t already followed the official guide, please try it and you’ll find how Contexts are really useful.

Also the routing guide as well as phoenix generators like Context generator, html genrator may be helpful. The generators are good prototype tools to generate code that you can cheat on to write your own. ^^

I have successfully updated my code but now getting one issue in case of edit if user does not follow any validation, then I throw a validation error but how to manage the form old value due to which he failed validation. Lets for example in case of edit we show data from DB for every form field and in one field if user clears the form field content and submit the form I show him error message like “can’t be blank” but on the form user again see the data from DB not the value the client has entered how to show the last form data user has entered while validating the form

<%= text_input f, :“card_expense”, value: “{card.card_expense}” %>

Isn’t it because you force the input to be prepopulated with the value of card.card_expense?

This is okay for new form, but for edit form` if you don’t want the behaviour you’re describing, you should not pre-populate the input value attr. If you create your update changeset like shown on most guides, you won’t have to pre-populate by hand your form inputs.

I would definitely look at the methods that is used on the form data. Because, its more secure to use POST methods instead of PUT, and I didn’t think cowboy supports that method. GET method is ok, for things that have not been stored by a user. POST method is the safest, as xml based hacks are all 100% urlencoded. If you don’t use a web server method. Its better to disable the unused methods so no one uses it as a attack vector.

The one thing I like about this, is that someone can’t mount the same attack like they can on ASP or PHP because there isn’t a destination they can attack to. So the only issues is xss and injection vectors from user input only while the consumer is using the application.

Its neat that there is a web based program programming language. But people need to get out of the thinking of “Website” and think along the lines of programming an electronic appliance like a Roku box.

So you have any references about this claim?

As far as I remember, both are pretty equivalent from HTTP point of view, just a different verb for otherwise equivalent requests. The main difference between both is the semantic…

Even though both procedures are considered unsafe, along with DELETE method, because they alter data, the use of an HTTP PUT method versus an HTTP POST method should be based
on the idempotent aspect of that operation. That is, if the operation is idempotent, then use the HTTP POST method. If the operation is non idempotent, then use the HTTP PUT method. But overall, things that end up on the url line in the browser can be manipulated. So its better to hide that communication from the url line. Technically, PUT, should be only used if the destination for the data can be reached through the url. So you wouldn’t want to use PUT for database entry. I remembered an issue where we blacklisted an e-commerce software on mine and other ISP where PUT and GET methods was used, and the combination of the WordPress XML-PHP module ended up with a security flaw that allowed anyone to go to the site, make and run a special XML query by opening up the browser’s HTML inspector, and get the database’s credentials and data.

Beyond this, I’m wonder how it handles the different error responses, and if its linked to the application crashes.

Mainly because one of the error catches of PUT is if the destination is not there, is to create the resource item. Post automatically assumes its a new item/resource, and doesn’t throw this error internally.

Sorry, I don’t get it. What does make one or the other more unsafe than the other?

Both require you (usually) to specify the resource in the URL and the data to change/create in the request body. None of the actual data should be in the URL.

Also your backend should properly authorise requests like those.

So whatever you are talking about is not an issue of HTTP verbs but the applications backend.

ok, I’ll try to simplify it. When PUT, POST, and DELETE was added, It was understood that PUT and DELETE was to be used for updating. Like an existing web page object rendered, or editing the HTML file itself. POST was to be used for adding Data. Like uploading files, and adding text to a database.

So which method is best? And how can someone sanitize a PUT object when its not a resource until it throws its own internal error?

Let me say again, whatever insecurity you see in any of the verbs (you still haven’t said what makes them insecure), its not there, at least not because of the verb itself. Any insecurities are by the backends implementation.

Well I don’t know how insecure this is, but when you use resources macro to add routes in your router, you can see the routes by running mix phx.routes, and PUT is one the methods you’ll see. So I think cowboy supports it.

The resources macro is so handful that you can specify only some actions, or exclude some, and it will generates the routes with the appropriate methods for you.

Example from the routing docs:

scope "/", HelloWeb do
  pipe_through :browser

  get "/", PageController, :index
  resources "/users", UserController
end

Then go to the root of your project, and run mix phx.routes

You should see something like the following:

user_path  GET     /users           HelloWeb.UserController :index
user_path  GET     /users/:id/edit  HelloWeb.UserController :edit
user_path  GET     /users/new       HelloWeb.UserController :new
user_path  GET     /users/:id       HelloWeb.UserController :show
user_path  POST    /users           HelloWeb.UserController :create
user_path  PATCH   /users/:id       HelloWeb.UserController :update
           PUT     /users/:id       HelloWeb.UserController :update
user_path  DELETE  /users/:id       HelloWeb.UserController :delete

Edit:
Then if we use Phoenix form_for helper to generate a form, we don’t have to set the method, just setting the action will be enough for the helper to add the appropriate method to the form. For example Routes.user_path(@conn, :edit, @user) as action will result in a form with POST as method. So personally I don’t worry about this detail. I let Phoenix handle it for me.