n atta kusi adusei
n atta kusi adusei
This PR does not use docker; I'm installing and configuring CockroachDB directly in Ubuntu, and it works OK. (If docker is preferred, please let me know) The problem is that...
I ran into a `Lucky::MissingParamError` with this a while back. My workaround looked like this: ```crystal params = URI::Params.encode({"codes[]": ["a", "b"]}) response = client.get("#{Reports::Query.url_without_query_params}?#{params}") response.status_code.should eq(200) ```
No, not now. I thought about it in the early days of *Shield*, but decided to postpone consideration. There's not a lot of open research on *passwordless* at the moment....
> I was looking for a login solution in lucky for one of my apps. Looks good! Glad to know. > The only thing I am missing is OTP/2FA support....
Depends on the nature of this metadata. `Lucky::Session#set` takes in only `String` values. If this metadata is a compound data type, you could `#to_json` it and set it in session,...
Lucky encrypts sessions server side, then stores them as cookies on the client (via the `Set-Cookie` response header). You may check Lucky's documentation at https://luckyframework.org, or view the source code...
> Is it possible to add a server-side storage for sessions which are not sent to clients? Check out https://github.com/KasKatto/redis-session. Shield will use whatever session handler your Lucky app uses....
Shield stores all data in the database. All secrets/tokens are stored as salted SHA-256 digests in the database. Generally, Shield stores users, passwords (bcrypt digests), emails, bearer tokens, password reset...
This should also account for situations where some of the many nested records have to be deleted when the parent operation is updated. In a create operation, the many nested...
Yeah, it should not raise. Can you post a stack trace? Where and how are you calling `#many_nested?`, since operations do not currently auto extract those from params?