(defn unquote-test* [form]
  (clojure.walk/postwalk (fn [form]
                           (if (and (seq? form)
                                    (= (first form)
                                       'clojure.core/unquote))
                             (eval (second form))
                             form))
                         form))

(defmacro unquote-test
  [form]
  (unquote-test* form))

(def a 42)

(unquote-test (+ 1 ~a))
;; 43

(macroexpand '(unquote-test (+ 1 ~a)))
;; (+ 1 42)

There is no helper to "eval all unquote"?

not sure what you're asking

Yeah it looks like there's no :pre/:post meta on a given defn's var. You could parse instead the output of clojure.repl/source

Why would you need a history of password hashes?

And by "write only" I guess you meant "append only".

@U2FRKM4TW, this is exactly my hesitation. This is what Rich Hickey seems to Advocate. I am having a hard time seeing it but it does simplify the code and it does add to history of user. Would it be useful? Its difficult to know.

It's not that normal to store the password hash, iteration and salt separtely.

they are normally part of the hashed password

i.e.,

echo -n "foobar" | argon2 $(date +%s) -t 300 -p 2 -e
$argon2i$v=19$m=4096,t=300,p=2$MTYyNDU0MDE2MA$dd3roHwKqQI9uFVkgzNk/UKeQI104Uk8I4iIDwrftOM

so the hash, i.e.,

$argon2i$v=19$m=4096,t=300,p=2$MTYyNDU0MDE2MA$dd3roHwKqQI9uFVkgzNk/UKeQI104Uk8I4iIDwrftOM contains the salt, iterations etc...

I've never had to store a history of hashes

which would open up a security risk, for if someone had the history of all the passwords that someone had....

@U012GN57FJ9 Rich argues that being able to see data history is useful. I would add to that that passwords are not data in that sense. Credentials are a means to access something right now. I cannot see how history of credentials could be useful, but I can definitely see how such a history could potentially be a hole in security.

And also what dharrigan said about storing all the hash parts together.

Thank you all, that makes sense.

One reason for keeping history of password hashes is to prevent reusing passwords. It used to be a OWASP best practice.

Makes sense. However, seems like they have redacted that recommendation? ASVS v3: "2.25 Verify that the system can be configured to disallow the use of a configurable number of previous passwords." ASVS v4: "2.1.10 Verify that there are no periodic credential rotation or password history requirements."

My knowledge might be outdated. 🙂

Edited my comment

Hmmm.. I’m a bit confused. In the stable version they still include checking previous passwords in #4 https://owasp.org/www-project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/04-Authentication_Testing/07-Testing_for_Weak_Password_Policy > How often can a user reuse a password? Does the application maintain a history of the user’s previous used 8 passwords?

Seems like ASVS != WSTG. Why they seemingly conflict on this particular matter, I have no clue.

To go back to the original topic. If I had to implement old password reuse prevention mechanism, I would go with a separate table that has nothing to do with authentication. It would store only old passwords' hashes and would be used only when a user is trying to change their password. The current password's hash would still be in the same table as the main user information.

the content type says application/x-www-form-urlencoded i can see the payload being sent from salesforce, but no dice

https://github.com/metosin/muuntaja can help

i was already using that...

i ended up making a conditional middleware based on the route that parses the body using slurp

can you try to dump the whole request map?

are you consuming the input stream before passing it to the middleware? for example, printing it for debugging? the request input stream that you get in the body of the request can only be processed once, so it'll need to be captured to be processed again

If I have this in CLJC file, the shadow-cljs compiler errors with EOF while reading.

that makes sense to me -there is nothing to read

I would guess yes if you were reading it using the Clojure reader, but no if you are reading it using ClojureScript reader

how do each of the compilers treat an empty file? because that fragment should be treated as if it were a lack of input

Well, for ClojureScript it is treated as if the file contained #_ and nothing else, yes? And that is probably why it is giving EOF, because the reader is not finding any following expression to omit

in both cases, read can't return you anything

I don't know about ClojureScript compiler, but the Clojure compiler has a pretty easy time with an empty file 🙂

depends if you're talking about load or read

something like (read-string {:read-cond :allow} "#_ #?(:clj :foo)") is going to throw with EOF as there is nothing to read and return. load is going to read and eval until it hits EOF, so it will just read nothing and stop.

How is it different from #_ :foo?

My file looks like so:

(ns ...)
#_ :foo
#_ :bar
#_ #?(:clj :foo)
#_ :baz

I think it is the same as reading a file with just this #_

Would be nice if the error in this case would be something like "no form after # to skip_"

Thanks @U8SFC8HLP , now I get it.

We wound up writing a new library (similar to sparkling) which we use in production for our big data processing jobs. https://github.com/amperity/sparkplug

Some of it (like the ML stuff) is incomplete, but the core APIs are all supported.

Oh sweet, I'll definitely take a look. Thanks!