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

passing a Buffer to waterline-sequel generates an incorrect query #64

Open
kevinburkeshyp opened this Issue Sep 23, 2015 · 5 comments

Comments

4 participants
@kevinburkeshyp
Contributor

kevinburkeshyp commented Sep 23, 2015

Same issue text as #61, which was closed. Steps to reproduce:

  • Create a column with type BYTEA in Postgres, say, passwordHash
  • You can't set it to type: 'bytea'in Waterline; it fails anchor validation in Waterline. Instead you have to use type: 'binary'
  • You can't pass strings as the value, even 'binary' encoded ones. it fails anchor validation with the cryptic string '[object Object]'
  • Anyway you finally manage to write data by passing a Buffer as the column value - {passwordHash: new Buffer('foo bar') }. The data looks like it got written properly!
  • you try to retrieve that data using Users.find({passwordHash: new Buffer('foo bar')});
  • Waterline-sequel (specifically, a call to _.cloneDeep) transforms this Buffer into a dictionary with many keys. I've reproduced this behavior in a gist here: https://gist.github.com/kevinburkeshyp/c45a344a15e040ec6f0e

Sorry I don't have time to find out exactly what's breaking - decided to bail on this and just use base64 and text instead.

@devinivy devinivy added the bug label Sep 23, 2015

@sailsbot

This comment has been minimized.

Collaborator

sailsbot commented Oct 24, 2015

Thanks for posting, @kevinburkeshyp. I'm a repo bot-- nice to meet you!

It has been 30 days since there have been any updates or new comments on this page. If this issue has been resolved, feel free to disregard the rest of this message. On the other hand, if you are still waiting on a patch, please:

  • review our contribution guide to make sure this submission meets our criteria (only verified bugs with documented features, please; no questions, commentary, or bug reports about undocumented features or unofficial plugins)
  • create a new issue with the latest information, including updated version details with error messages, failing tests, and a link back to the original issue. This allows GitHub to automatically create a back-reference for future visitors arriving from search engines.

Thanks so much for your help!

@sailsbot sailsbot closed this Oct 24, 2015

@devinivy

This comment has been minimized.

Contributor

devinivy commented Oct 24, 2015

Active bug.

@devinivy devinivy reopened this Oct 24, 2015

@tjwebb

This comment has been minimized.

Contributor

tjwebb commented Oct 25, 2015

@kevinburkeshyp

This comment has been minimized.

Contributor

kevinburkeshyp commented Oct 25, 2015

Hey I haven't done a full investigation but I believe the issue is more likely to be here than there. Although any place that calls cloneDeep on input will be vulnerable so it might be this repo and that one.

-kevin

On Oct 24, 2015, at 19:55, Travis Webb notifications@github.com wrote:

@kevinburkeshyp related to balderdashy/sails-postgresql#194? a dupe?


Reply to this email directly or view it on GitHub.

@tjwebb

This comment has been minimized.

Contributor

tjwebb commented Oct 25, 2015

Any help in eradicating cloneDeep is appreciated. It'll be a couple weeks before I'll be able to dig into this.

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