We are trying to implement single sign on, across multiple domains from MVC 4 application to .Net Core application.
MVC 4 to MVC 4 it's working fine with MachinKey, but not with .Net core.
How can we implement SSO to share the same authentication with all other application in MVC4 and .Net core application.
Identity Server can do this. Identity Server version 4 will be supported and free for as long as .NET Core 3.1 is supported. After that, you'll need Duende Identity Server, which is the next version, available on a commercial licence.
You can also do it with OpenID Connect (AKA OpenIddict) which is free for the foreseeable future, but that will probably need you to write a bit more code.
I have used both.
Both of them are agnostic to the type of client applications, so your clients can be MVC4, .NET Core, Xamarin, React, anything at all. Both of them have good templates that you can download and get started quite quickly with a simple scenario.
Unfortunately, in my experience, making meaningful extensions or changes to the templates (such as what you're proposing) was difficult and required in-depth knowledge of internet security concepts, studying the documentation and source code of whichever library that you choose.
I have tried really hard to learn but I still find it difficult, so I wish you good luck!
Here are the sample projects for IdentityServer4:
https://github.com/IdentityServer/IdentityServer4.Templates
And here is the documentation on how to get started:
http://docs.identityserver.io/en/latest/
Here are the sample projects for Open Id Connect:
https://github.com/openiddict/openiddict-samples
And here is the documentation:
https://openid.net/connect/
I am trying to implement speech to text on my .net core 3.1 web app without using any cloud services like Azure, AWS, or Google.
I have found options like deepspeech, kaldi,pocketpheonix. It looks like they can be implemented on a .net core app but being a beginner in .net core and backend development I don't know how to use them and their documentation is not very beginner-friendly.
So if you can provide a brief overview of how to implement these apis on .net core or link to some articles, that would be very helpful.
Just my personal view, some Kaldi or PocketSphinx experts might have a different view.
Kaldi + PocketSphinx
You will need to compile all sources yourself on Windows and Kaldi is a headache to build on Linux, so I guess it is not much better on Windows. That said, they use less resources and are usually quicker.
DeepSpeech
Just download the current English acoustic model (pbmm) and language model (scorer) and use the .NET example code. Should work without compilation.
Was Kestrel present in .NET Framework or was it developed specifically for the ASP.NET Core?
I was not able to find an answer to this question by just googling, so I decided to ask it here. I need it because I am intended to work with the ASP.NET Core and would like to know the history of development better, because knowing it allows to better understand the decisions made by developers.
In order to give an official answer to this question, I copy here comments from #AnkushJain and #andrew-morton:
Kestrel is not available for .NET Framework. It is born with the origin of ASP.NET Core.
[In addition] since Kestrel is not a fully-featured web server, you should run it behind IIS or NGINX. It was designed to make ASP.NET as fast as possible but is limited in its ability to manage security and serve static files.
Our app is based on ASP.NET Core 2.0. It works fine in development environment but we see an oauth error when published to production.
All the documentation on asp.net core seems to point to using ILoggingxxx interfaces. The examples I found typically call logging.AddConsole() method so that the log lines can be viewed in VIsual Studio debug window. I am wondering if the good old trace.axd is still available under asp.net core. If so, I would appreciate the steps to enable tracing. Regards.
trace.axd is exclusive to applications based on .NET Framework and ASP.NET 4.x. It is not available in ASP.NET Core applications at all.
With ASP.NET Core 1.0 release one can run on either .NET Core or the full .NET Framework per the documentation here. I'm trying to understand the latter option of why one would select ASP.NET Core + the full .NET Framework?
I understand the difference between the full .NET Framework and .NET Core. However, if I wanted to use the full .NET Framework, why not just use ASP.NET 4.6? I thought the idea was a 1-2 punch with ASP.NET Core atop of .NET Core allowing the slew of benefits like cross platform deployment, modularization, ability to deploy to a Docker container, performance, etc. Without .NET Core I don't believe anything on that list is still valid, so what is the use case for the full .NET framework + ASP.NET Core? What does ASP.NET Core on it's own still provide to me without .NET Core?
.NET Core allowing the slew of benefits like cross platform deployment, modularization, ability to deploy to a Docker container, performance, etc.. Without .NET Core I don't believe anything on that list is still valid
The only benefit you don't have if you choose the full .NET framework over .NET Core is being cross platform. All the other benefits of deployment, modularization, docker, performance, etc... are still valid.
We actually run our ASP.NET Core web app on the full framework and now we enjoy the benefits of having Dependency Injection as a 1st class citizen, having NuGet built in, having an lean HTTP request pipeline which makes our performance better, open sourced (so all the issues can be solved by a short visit to GitHub), modularity (still have to come across something we couldn't customize to our own needs after almost a year now), and so on. And we know we don't need to deploy on any other OS than Windows, so we can still have all the benefits of the full framework.
Update from Tseng
Well, you can still target full .NET Framework under Linux for example. There you need mono 4.6 installed there. There are some limitations as not all classes are implemented in mono, but a majority is and around the corner case (i.e. encryption) you have to work around
Update from atconway
It's also worth noting at the time VB.NET is not supported by .NET Core if that's a requirement.
However, if I wanted to use the full .NET Framework, why not just use ASP.NET 4.6?
If I use ASP.NET 4.6 instead of ASP.NET Core 1, then I won't be able to use ASP.NET Core MVC. None of the features on that documentation page would be made available to me! I would have to build an MVC5 application. Boooo!
I'm trying to understand the latter option of why one would select ASP.NET Core + the full .NET Framework?
I'm assuming that another way to ask this would be: "why would you take the red path when you can take the brown path?"
One argument for doing it this way is deployment. If you've got a bunch of existing Windows servers with IIS on them, you're going to need to install additional software on each of them and set them up to run Core applications. IIS just becomes a reverse proxy for your .NET Core app.
However, if these apps were built on the .Net Framework instead, you wouldn't have to do this. You could still use web deploy (for example) to move them onto the servers. Maybe you've got some other existing IIS configuration settings that you don't want to migrate.
Using ASP.NET Core 1.0 targeting the .Net Framework, you can get the benefit of the new features in ASP.NET Core MVC without having to change your existing infrastructure.
One important benefit of using Full .NET framework with Asp.Net core is availability of mature libraries and frameworks that are developed mainly to target previous version of .NET.
But by passing of time and implementing more and more libraries to target .NET core and developing more features for .NET core itself this benefit may fade out.
Having to leverage legacy technologies like OLE DB that will never be implemented in NET Core System.Data is another reason.
One thing to consider is that it can be a migration path. Say, for example, you have an existing ASP.NET 4.6 application that you intend to migrate to .NET Core. You want to take advantage of ASP.NET Core features like TagHelpers, Dependency Injection, etc., but you aren't ready or able to use .NET Core framework. So, you develop the ASP.NET Core application, targeting just the .NET full framework. Then, you take the next step and multi-target, going for both .NET full framework and .NET Core framework. This gives you the flexibility to easily deploy to IIS with the full framework or cross-platform with the core framework. From there, you can decide if you want to eliminate the full framework or not.