Also hopefully these are behind authenticated routes, so if users are code-injecting themselves maybe thats their own perogative.
So for now I will change these to type &str, and we can test it out a bit, and confirm its all still working.
I think we should be safe from code injection attacks, as long as we don't pass…
@glyph from what I'm reading in the documentation, I think in rocket 0.5 its not the intention to use RawStr as a type for a route parameter, but rather to put validation and parsing into…
(I wrote above comment at the same time as your comment and hadn't read it yet, btw)
my initial guess is that rocket0.4 didn't handle utf-8 in query strings well?
In 0.5 documentatation they explicitly mention that they allow utf8-strings in query parameters (and all forms) now. …
also for ergonomics, SbotcliApi object could just be called Sbot
not sure if it makes more sense for a rust library to be configured via env variables, or explicitly via instantiating an object with arguments, or both.
perhaps with an object is more modular,…
could also consider to do an object-oriented pattern, with something like:
- a function to instantiate an SbotcliApi object (with optional arguments to pass flags like sbotcli_path, and working…
^^ sounds good.
As I mentioned in this comment
/// currently go-sbotcli determines where the working directory is |
1aa5821adf
Merge pull request 'Refactor routes into functional groupings' (#12) from routes-refactor into main
All points sounds good to me.
The third style, hmmm.. interestingly in my IDE, it only shows up bold when a # is used inside of /// (not a //).
Ideally would also like to avoid a pattern…
in general I think we should also value "developer efficiency" (ease of working with, understanding and making changes to the code) for the patterns we use, in addition to "compile time and binary…
LGTM
comments here PeachCloud/peach-workspace#9 (comment)