This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
- # arachne (1)
- # bangalore-clj (11)
- # beginners (177)
- # boot (63)
- # business (1)
- # cljsjs (21)
- # cljsrn (3)
- # clojars (4)
- # clojure (116)
- # clojure-art (4)
- # clojure-belgium (3)
- # clojure-india (1)
- # clojure-italy (6)
- # clojure-russia (14)
- # clojure-spec (8)
- # clojure-uk (67)
- # clojurescript (51)
- # community-development (5)
- # cursive (13)
- # datascript (14)
- # datomic (29)
- # devcards (3)
- # emacs (3)
- # events (3)
- # funcool (4)
- # hoplon (29)
- # mount (6)
- # om (34)
- # om-next (5)
- # onyx (16)
- # perun (8)
- # planck (22)
- # re-frame (13)
- # reagent (5)
- # ring-swagger (21)
- # rum (3)
- # spacemacs (3)
- # specter (1)
- # untangled (39)
Universal Greeting Time: http://www.total-knowledge.com/~ilya/mips/ugt.html
Shameless self plug: https://twitter.com/skillsmatter/status/801714732587683840
It's about simplifying the way you interact with remote APIs and making the integration generative-testable, but I'm rubbish at writing synopses
perhaps it should be UTG, so as not to offend any non-english sensibilities @agile_geek ?
@mccraigmccraig maybe the phrase 'Universal Greeting Time' should be translated to Esperanto?
if anyone would like to feature on https://juxt.pro/clojure-in.html please let me know - the end of the pipeline is becoming visible
Does anyone have experience 'proxying' multi-part uploads from one server to another? I have a server which expects multipart and have now introduced a front-facing gateway/BFF which is supposed to proxy requests. Simple for most requests but...tricky for multipart. Is this even a thing?
@acron can you not just forward the body-stream after parsing the headers to determine destination ?
I'm fine w/16 bit ones. I'm just thinking big enough to do everything, small enough to not be an attack vector. 😉
if you end up having to parse the multipart stream @acron then @malcolmsparks work may help - https://github.com/juxt/yada/blob/master/src/yada/multipart.clj
I presume it is just a string and if it is long then bcrypt will take more time to hash it
> the key argument is a secret encryption key, which can be a user-chosen password of up to 56 bytes (including a terminating zero byte when the key is an ASCII string). from http://security.stackexchange.com/questions/39849/does-bcrypt-have-a-maximum-password-length
@mccraigmccraig Thanks, I will have a look at this - it could be as simple as handling the body stream, I haven't tried yet 😎
anyone who is picking passwords between 50 and 150 chars probably knows enough to expect some truncation along the way?
emojis are probably making their way onto dictionary attacks, maybe I should include some cuneiform?
wow - 56 characters doesn’t sound all that much, really. Though that’s my brain being illogical - part of me thinks “I went from an 8 character password 10 years ago to a 16 character password now, I guess I’ll have to keep doubling” 🙂
I guess if people enter a 100 character password, they are probably making false assumptions. I don’t like the idea of limiting though, at some level.
acron I wonder what NIST are hashing with then at 8 ish chars of that won't make a difference
ie: enter password successfully -> try and enter again and get wrong password. but it did work if you filled in only the first 12 char of original.
@acron if you need to produce (as opposed to parse) a multipart message, also this can help: https://github.com/reborg/applenews-api/blob/master/src/net/reborg/applenews_api/multipart.clj