Getting some error from JWT with Lumen:
Could not create token: Implicit conversion of keys from strings is deprecated. Please use InMemory or LocalFileReference classes
https://github.com/tymondesigns/jwt-auth/issues/2059
Any suggestion to do a quick fix, it seems a bug in new version.
On this thread, two solutions has been proposed as quickfix:
Solution 1:
In config\jwt.php file Change 'jwt' =>
Tymon\JWTAuth\Providers\JWT\Lcobucci::class, to 'jwt' =>
Tymon\JWTAuth\Providers\JWT\Namshi::class,
=> It works for me <3
Solution 2:
lcobucci/jwt:3.4 has this problem, composer require lcobucci/jwt:3.3 can resolve it.
It seems to be a problem with the lastest jwt package release (3.4.0)
Related
For example, I have Map<int, int> m;. Then I can write down m['hello'] without any compile-time error, but of course, cannot find any element at runtime. I hope it will produce an error (or warning) at compile-time or lint time.
This is a big problem in many cases. For example, when I refactor Map<A, int> m into Map<B, int> m, I want to have compile-time errors for all accesses like m[some_var_of_type_A], instead of no compile-time errors and suddenly it explodes at runtime. As another example, the de-serialized JSON is of type Map<String, ...> but the key is actually a int. So it is tempting to do var userId=42; deserializedJson[userId] but only to find errors. Actually need to do deserializedJson[userId.toString()].
You know, dart's type system is so strong (even null safe!), and I really enjoy it since it catchs a LOT of bugs at compile-time. So I hope this problem can also be addressed at compile-time.
Thanks for any suggestions!
There currently is no lint to warn about doing lookups on a Map with arguments of the wrong type. This has been requested in https://github.com/dart-lang/linter/issues/1307.
Also see https://github.com/dart-lang/sdk/issues/37392, which requests a type-checked alternative to Map.operator []. In the meantime, Dart's extension mechanism allows anyone to easily add such an alternative themselves. For example, package:basics provides a type-checked Map.get extension.
NOTE:
The original answer was wrong and has been edited to:
point out the right/better answer
explain why the original answer was wrong
Thank you #jamesdlin for pointing this out.
Better answer
As pointed by #jamesdlin in his answer, the lint rule mentioned in the question has been requested in the flutter Github issues, and not in production yet.
Original Answer (wrong but kind of related to the question)
Why it is wrong:
The question was asking about the lint rule when using an index of Map. The answer however gave the lint rule about initializing a map using the wrong index (By the wrong index, I mean different data type).
Below is the answer:
There is a lint rule for this.
For example, if you define a Map like this ->
final Map<String, String> m = {
1: 'some random value',
};
It shows an error right away and this won't compile. This is the error ->
Error: A value of type 'int' can't be assigned to a variable of type 'String'.
1: 'error because index is of type String but assigned value is of type int',
^
Error: Compilation failed.
See the official docs where this lint rule, map_key_type_not_assignable is defined.
I have tested this in dartpad and vs code. Both IDEs show this error.
There could be some issues in your IDE configuration if you're not seeing this lint error.
As for your question, there is already a lint rule for this as explained above.
I am learning Yesod and was looking for postgresql usage examples in ghci when I ran into this
How to perform database queries in GHCi in Yesod Application
pcon <- openSimpleConn con
The package has changed since this answer was given and now openSimpleConn requires a LogFunc in addition to the Connection string. Reading the docs for openSimpleConn and LogFunc does not yield any examples regarding where to get a LogFunc or how to use one (I am still new to Haskell)
Assuming it wants some kind of logging function, I tried doing
pcon <- openSimpleConn runStdoutLoggingT con
But this was met with
<interactive>:22:9: Not in scope: ‘runStdoutLoggingT’
At which point I decided I needed some help.
So, my questions are, what is a LogFunc and what is the proper way to get and use one?
The simplest implementation you can use it \_ _ _ _ -> return (), i.e., ignore all arguments and do nothing. For more details on what's going on, check out the monad-logger package.
I was using guava 14 to do String hashing like so:
Hashing.sha256().newHasher().putString("String").hash().toString();
=>
4d1ca6dce72e20ce214b706168340683bb6b571a7c977c1a9fe029a1cc1c4d06
just upgraded to guava16,
calling this function:
Hashing.sha256().newHasher().putString("String", Charsets.UTF-8).hash().toString() gives me a different result.
=>
b2ef230e7f4f315a28cdcc863028da31f7110f3209feb76e76fed0f37b3d8580
I suspect that the old version was using default charset, but switching Charsets on guava16 doesn't give me the same result as in guava14. What did I do wrong here?
As stated in the docs of Guava 15, the replacement for the old putString(String) method is putUnencodedChars.
As Louis said, the replacement is Hasher.putUnencodedChars(). Or, you can use the shortcuts on the HashFunction interface:
Hashing.sha256().hashUnencodedChars("String").toString();
I encountered this problem while posting this question: Slick Write a Simple Table Creation Function
I am very new to Slick and concurrency, knowing only the basics. I worked with JDBC before, but in there you have to manually open a session and then close it. Nothing goes beyond that, and there is very little automation (at least I didn't have to make automated process).
However, I get confused with Slick session. In the tutorial, the example "Getting Started" encourages people to use threadLocalSession:
// Use the implicit threadLocalSession
import Database.threadLocalSession
http://slick.typesafe.com/doc/1.0.0/gettingstarted.html
The original recommendation is:
The only extra import we use is the threadLocalSession. This
simplifies the session handling by attaching a session to the current
thread so you do not have to pass it around on your own (or at least
assign it to an implicit variable).
Well, I researched a bit online, and some people suggest not to use threadLocalSession and only use implicit session. Some suggest using threadLocalSession.
One reason to support implicit session is that "makes sure at compile time that you have a session". Well, I only have two questions:
When people use "thread", are they referring to concurrency? Slick/JDBC data storage was handled through concurrency?
Which way is better? Implicit or threadLocalSession? Or when to use which?
If it is not too much to ask, I read the syntax of {implicit session:Session => ...} somewhere in my Scala book, and I forgot where it was. What's this expression?
A threadLocalSession is called this way because it is stored in a "thread local variable", local to the current execution thread.
As of Slick 2, we recommend not to use threadLocalSession (which is now called dynamicSession) unless you see a particular need for it and are aware of the disadvantages. threadLocalSession is implicit, too, by the way. The problem is, that a threadLocalSession is only valid at runtime when a withSession (in Slick 2.0 withDynSession) call happened somewhere down the call stack. If it didn't the code still compiles but fails at runtime
{implicit session:Session => ...} is a function from (the explicitly annotated type) Session to ..., where the session is available as an implicit value in ... . In db.withSession{ implicit session:Session => ... }, db creates a session, passes it into the closure handed to withSession. In the closure body ..., the session is implicit and can implicitly used by .list calls, etc.
Consider something like this:
object Singleton
val cls: Class[Singleton] = ???
What do I have to write instead of ????
I tried classOf[Singleton], classOf[Singleton.type], Singleton.type, but nothing worked.
(I know of course about getClass, the runtime version of classOf, but that's not what I'm asking.)
Here a solution, but it's not pretty ...
object Singleton
val cls : Class[Singleton] = Singleton.getClass.asInstanceOf[Class[Singleton]]
Edit: completed the solution after reading another question/answer: Scala equivalent of Java java.lang.Class<T> Object
Note1: type erasure would prevent this from being particularly useful, e.g. in pattern matching. See referenced question/answer, above, for a good explanation
Note2: the scala -explaintypes flag is quite handy in understanding type errors.
HTH
You are not alone with this problem. The answer is: There is currently no way to avoid a Singleton.getClass. See this comment for more information why classOf[Singleton] does not work