You can disable requiring secure connections during dev with:
new JwtAuthProvider(AppSettings) {
RequireSecureConnection = !Config.DebugMode
}
But MQ endpoints aren’t secure, are you getting this error trying to execute MQ request?
Yes, its from the dlq of the Message Handler
Ok this check should be ignored for MQ requests, I’ve added a fix for this in the latest v6.1.1 that’s now available on MyGet.
Or you can disable this restriction with RequireSecureConnection=false until the next official release which should be out soon.
1 Like
That’s great - thanks for your help sorting this out and for the quick turnaround on a fix.
1 Like
Using vs code and struggling to set MyGet up. Have followed the instructions but on a nuget restore it only restores 6.0.0
Need more information to be able to help, are you using a 6.* wildcard? is your NuGet.config next to your .sln?
Sorry, yes, I followed the instructions so nuget.config is a sibling to the .sln file and I hard coded the csproj to 6.1.1…
Can you use a wildcard, to ensure all dependencies reference the same & latest version.
Can you use the NuGet.config instead as per the docs instead of what you’re doing, MyGet should be the first source listed.
You can download it using x mix in the directory with your .sln:
$ x mix myget
Will change to a wildcard, thanks.
I did that but it overwrote my company source and credentials
So you have an existing NuGet.config? Either way I believe MyGet needs to be listed first to be able to use it.
If you always use a 6.* wildcard for ServiceStack packages, you can simply remove the package source and restore to update when the new release is out, rather than manually specifying version numbers which wont exist after the new release is published.
1 Like
So I’m definitely using 6.1.1
But I’m getting the same problem; although now the stack trace has gone so something has changed…
No idea then, try debugging to see where what’s throwing the error, or I could debug it if you provide a repro.
Fair enough. To be honest I’m not Sure how long it will take me to produce a repro. We have so many moving parts and services that are communicating with each other.
I’ll try get something together over the weekend.
It sounds like debugging ServiceStack would require the least effort, basically debugging where the Exception is thrown to check the state of the MQ IRequest to see why the check is failing.
1 Like
I’ve…
switched to vs studio pro,
cleared the nuget cache,
ensured myget is first in nuget.config,
Enabled server link support,
disabled just my code…
…but not breaking on any exceptions thrown by ServiceStack.
Is there a way I can add a breakpoint in ServiceStack source to test its set up correctly?
Can you ctrl+click on a file then set a breakpoint to start debugging, e.g. in MessageHandler.cs before the message is processed, then debug from there?
I typically get message that from dirty builds, try doing a clean build/restore by deleting /bin and /obj and clearing your NuGet packages cache:
$ nuget locals all -clear
and doing a full restore & rebuild, hopefully the issue was that it wasn’t using the latest v6.1.1 on MyGet.
I’ve been unable to make any headway into this. I’ve found the use of ErrorMessages.JwtRequiresSecureConnection but my ServiceStack source code is different to what’s showing on the GitHub repo. I’ve deleted bin and obj, shutdown VS, cleaned the nuget caches, done a full restore and rebuild but nothing changes.
Will keep trying though
I’m going to switch to RequireSecureConnection = false for now. I can’t work it out and am sure I’m using 6.1.1 (built 22-07-15 at about 7pm - according to the dll properties in the bin folder)