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

Long commit message causes postgres insert error #914

Closed
logan opened this Issue Mar 12, 2015 · 4 comments

Comments

Projects
4 participants
@logan

logan commented Mar 12, 2015

The postgres schema for commits uses VARCHAR(255) for the message. If the commit message exceeds this length, then an error occurs trying to commit the commit to the DB.

By the way, the error handling in the hook handler leaves a lot to be desired. A lot of these 400s really should be 500s, and all of them discard the error string instead of logging or returning it, leaving us guessing as to the cause.

@bradrydzewski bradrydzewski added the 0.4.0 label Jul 22, 2015

@bradrydzewski bradrydzewski modified the milestone: v0.4.0 Aug 18, 2015

@bradrydzewski bradrydzewski changed the title from Long commit message causes webhook handler to return 400 to Long commit message causes postgres insert error Aug 18, 2015

@bradrydzewski bradrydzewski removed the 0.4.0 label Aug 22, 2015

@bradrydzewski bradrydzewski modified the milestones: v0.4.1, v0.4.0 Aug 22, 2015

@bradrydzewski bradrydzewski modified the milestones: Unplanned, v0.4.1 Jul 11, 2016

@tboerger

This comment has been minimized.

Show comment
Hide comment

@bradrydzewski bradrydzewski added this to To Do in Version 0.7 May 11, 2017

@bradrydzewski bradrydzewski removed this from the Unplanned milestone May 13, 2017

bradrydzewski added a commit that referenced this issue May 14, 2017

@bradrydzewski bradrydzewski moved this from To Do to Done in Version 0.7 May 14, 2017

@thomasf

This comment has been minimized.

Show comment
Hide comment
@thomasf

thomasf May 15, 2017

Contributor

Always use text fields to represent text, varchar should only be used to validate text types which has a known maximum length.
Looking at the migration sql files it seems that many varchar columns which probably should be text

Contributor

thomasf commented May 15, 2017

Always use text fields to represent text, varchar should only be used to validate text types which has a known maximum length.
Looking at the migration sql files it seems that many varchar columns which probably should be text

@bradrydzewski

This comment has been minimized.

Show comment
Hide comment
@bradrydzewski

bradrydzewski May 15, 2017

Member

I think putting limits on column size is a good thing. We don't want to accept a hook with a 1GB commit message for example.

Member

bradrydzewski commented May 15, 2017

I think putting limits on column size is a good thing. We don't want to accept a hook with a 1GB commit message for example.

@thomasf

This comment has been minimized.

Show comment
Hide comment
@thomasf

thomasf May 15, 2017

Contributor

The kind of validation you are talking about now should probably be done before parsing a request using maximum "request" size check while or before reading..

I guess having the database do some checks as well isn't too bad, I see that you also truncate the message if it's too long..

You could easily multiply your current limits by 100 and still be relatively safe though.

Contributor

thomasf commented May 15, 2017

The kind of validation you are talking about now should probably be done before parsing a request using maximum "request" size check while or before reading..

I guess having the database do some checks as well isn't too bad, I see that you also truncate the message if it's too long..

You could easily multiply your current limits by 100 and still be relatively safe though.

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