I need to generate and hash a token for passwordless login. I was wondering if FQL can be used to generate a random string and then to hash it with SHA256? What about generating a simple auto incrementing key on insert like you can do with MySQL etc.?
You have several different questions here. The incrementing key is probably easier to talk about first.
This has been covered in a previous topic:
- Every document has a unique id that uses the snowflake algorithm. Whenever you can, you should rely on the id’s provided to new documents.
- You can use the
NewIdfunction to generate an ID as well.
- You can create a UDF that increments a value, saves it, and returns it. WARNING – this can easily create write-contention issues if you try to call it too often. The linked post mentions “conflict free” counters, which is not implemented yet but still on the roadmap.
There is no built-in functionality for random numbers, yet. You can get a pseudo-random implementation together using FQL, though. You can follow this discussion in this previous topic:
Depending on your implementation you may also need to worry about contention. For example, this implementation saves a seed value in a document and iterates that seed on every call. If the random function needs called often then the each potential caller (user) can store their own random seed to avoid contention.
Also, let us put a lot of emphasis on pseudo-random. I wouldn’t trust it for anything you actually need crypto-protected. But we know this has been used successfully to offer users random awards, for example.
Today I learned about the SHA-256 algorithm!
Reviewing the explanation here, it is certainly possible to create an FQL expression to calculate a SHA-256 hash. You could even use it as Index binding! FQL is quite powerful that way.
But you should hesitate to use FQL as a general compute engine. Calculating a single SHA-256 could cost 70+ Compute Ops. So, it is probably a very bad idea to create a SHA-256 index binding
Part of this is FQL lacking bit-shift operators. Part of this is that there is plainly a lot of operations to perform.
It’s definitely now on my list to try my hand at it, though!
You can provide
credentials when you
Create a document, and the
password is saved as a hashed value. You can also create Credentials Documents directly. If you are interested in storing a hashed value given a string, you might consider creating a document with a password set to that string.
Such a document would not be used for login or for providing tokens, but you can still use the
Identify function to check a string against that hashed password.