Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

allow ignoring field on form mapping #1733

Merged
merged 3 commits into from Feb 22, 2019
Merged

Conversation

bazaglia
Copy link
Contributor

@bazaglia bazaglia commented Jan 5, 2019

As discussed in issue #610 when using c.Bind(), sometimes we don't want to bind certain fields from the user request. While this can be done adding json:"-" to field tag, the same can't be achieved for multipart/formdata requests.

This PR allows setting in the tag form:"-", which solves the described issue.

@bazaglia bazaglia changed the title fix(binding): avoid mapping nonexistent form tag allow ignoring field on form mapping Jan 5, 2019
@codecov
Copy link

codecov bot commented Jan 7, 2019

Codecov Report

Merging #1733 into master will increase coverage by <.01%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #1733      +/-   ##
==========================================
+ Coverage   98.48%   98.48%   +<.01%     
==========================================
  Files          41       41              
  Lines        2047     2049       +2     
==========================================
+ Hits         2016     2018       +2     
  Misses         19       19              
  Partials       12       12
Impacted Files Coverage Δ
binding/form_mapping.go 100% <100%> (ø) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 4e86b17...11afd07. Read the comment docs.

@thinkerou
Copy link
Member

thinkerou commented Jan 20, 2019

not json:"-" but binding:"-" which also can use for multipart/formdata, thanks!

type LoginForm struct {
	User     string `form:"user" binding:"required"`
	Password string `form:"password" binding:"-"`
}

func main() {
	router := gin.Default()
	router.POST("/login", func(c *gin.Context) {
		var form LoginForm
		if c.Bind(&form) == nil {
			c.JSON(200, gin.H{"msg:": form.User + " " + form.Password})
		}
	})
	router.Run(":8080")
}

curl -v --form user=user --form password=password http://localhost:8080/login
curl -v --form user=user --form password1=password http://localhost:8080/login

@bazaglia
Copy link
Contributor Author

bazaglia commented Jan 21, 2019

@thinkerou hey, thanks for your comment.

problem is, as my comment here #610 (comment), gin uses binding for validation. That means the field still decoded by c.Bind even when setting binding:"-". That was I added form:"-", that's corresponding to json:"-", but for forms.

In your example, when printing form.Password, it won't return a nil pointer (<nil>), but a memory address (like 0xc00001e510 that points to an empty string). This is really anoying specifically when saving data to a SQL database (it will save an empty string, not null)

binding/binding_test.go Outdated Show resolved Hide resolved
@hotcoffie
Copy link

its not working properly now. When I added form:"-" to my field, the field is still being assigned a value regardless of whether I use Bind or ShouldBind.

type Astruct struct {
	Aa string  `form:"-" json:"aa"`
	Bb *string `form:"-" json:"bb"`
}

func Init(r *gin.Engine) {

	api := r.Group("/api")
	{
		api.GET("/ping", func(c *gin.Context) {
			c.JSON(http.StatusOK, "pong")
		})

		api.POST("/test", func(ctx *gin.Context) {
			var a Astruct
			ctx.Bind(&a)
			fmt.Println(a.Aa)
			fmt.Println(*a.Bb)
			ctx.AbortWithStatus(http.StatusOK)
		})
	}
}
POST http://127.0.0.1:9527/api/test
Content-Type: application/json

{
	"aa": "a",
	"bb": "b"
}
a
b
2023-09-05T01:30:16.577+0800	DEBUG	utils/logger.go:43	gin	{"method": "POST", "path": "/api/test", "status": 200, "ip": "127.0.0.1", "elapsed": "243.845µs"}

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants