Website:
The Web Site project is compiled on the fly. You end up with a lot more DLL files, which can be a pain. It also gives problems when you have pages or controls in one directory that need to reference pages and controls in another directory since the other directory may not be compiled into the code yet. Another problem can be in publishing.
If Visual Studio isn't told to re-use the same names constantly, it will come up with new names for the DLL files generated by pages all the time. That can lead to having several close copies of DLL files containing the same class name,
which will generate plenty of errors. The Web Site project was introduced with Visual Studio 2005, but it has turned out not to be popular.
Web Application:
The Web Application Project was created as an add-in and now exists as part
of SP 1 for Visual Studio 2005. The main differences are the Web Application Project
was designed to work similarly to the Web projects that shipped with Visual Studio 2003. It will compile the application into a single DLL file at build
time. To update the project, it must be recompiled and the DLL file
published for changes to occur.
Another nice feature of the Web Application
project is it's much easier to exclude files from the project view. In the
Web Site project, each file that you exclude is renamed with an excluded
keyword in the filename. In the Web Application Project, the project just
keeps track of which files to include/exclude from the project view without
renaming them, making things much tidier.
Reference
The article ASP.NET 2.0 - Web Site vs Web Application project also gives reasons on why to use one and not the other. Here is an excerpt of it:
- You need to migrate large Visual Studio .NET 2003 applications to VS
2005? use the Web Application project.
- You want to open and edit any directory as a Web project without
creating a project file? use Web Site
project.
- You need to add pre-build and post-build steps during compilation?
use Web Application project.
- You need to build a Web application using multiple Web
projects? use the Web Application project.
- You want to generate one assembly for each page? use the Web Site project.
- You prefer dynamic compilation and working on pages without building
entire site on each page view? use Web
Site project.
- You prefer single-page code model to code-behind model? use Web Site
project.
Web Application Projects versus Web Site Projects (MSDN) explains the differences between the web site and web application projects. Also, it discusses the configuration to be made in Visual Studio.
Note: Read the comments of this answer, it can produce a XSS Vulnerability if you are using the default error handing of WebAPI
I just add the following in App_Start / WebApiConfig.cs
class in my MVC Web API project.
config.Formatters.JsonFormatter.SupportedMediaTypes
.Add(new MediaTypeHeaderValue("text/html") );
That makes sure you get JSON on most queries, but you can get XML
when you send text/xml
.
If you need to have the response Content-Type
as application/json
please check Todd's answer below.
NameSpace
is using System.Net.Http.Headers
.
Best Solution
Note/Update:
The below code was for .NET Core 1.1
Since .NET Core 1 was so very RTM, authentication changed with the jump from .NET Core 1 to 2.0 (aka was [partially?] fixed with breaking changes).
That's why the bellow code does NOT work with .NET Core 2.0 anymore.
But it will still be a useful read.
2018 Update
Meanwhile, you can find a working example of ASP.NET Core 2.0 JWT-Cookie-Authentication on my github test repo. Comes complete with an implementation of the MS-RSA&MS-ECDSA abstract class with BouncyCastle, and a key-generator for RSA&ECDSA.
Necromancing.
I digged deeper into JWT. Here are my findings:
You need to add Microsoft.AspNetCore.Authentication.JwtBearer
then you can set
in Startup.cs => Configure
where bearerOptions is defined by you, e.g. as
where CustomBearerEvents is the place where you could add token data to the httpContext/Route
And tokenValidationParameters is defined by you, e.g.
And MyTokenHandler is optionally defined by you, if you want to customize token validation, e.g.
The tricky part is how to get the AsymmetricSecurityKey, because you don't want to pass a rsaCryptoServiceProvider, because you need interoperability in crypto format.
Creation goes along the lines of
e.g. with BouncyCastle from a DER Certificate:
Subsequently, you can add a custom cookie-format that contains the JWT-Bearer:
Where CustomJwtDataFormat is something along the lines of
And you can also create the JWT-token with Microsoft.IdentityModel.Token:
Note that because you can give a different user in the cookie vs. http-headers (Bearer), or any other authentication method that you specify, you can actually have MORE than 1 user !
Take a look at this:
https://stormpath.com/blog/token-authentication-asp-net-core
it should be exactly what you're looking for.
There's also these two:
https://goblincoding.com/2016/07/03/issuing-and-authenticating-jwt-tokens-in-asp-net-core-webapi-part-i/
https://goblincoding.com/2016/07/07/issuing-and-authenticating-jwt-tokens-in-asp-net-core-webapi-part-ii/
and this one
http://blog.novanet.no/hooking-up-asp-net-core-1-rc1-web-api-with-auth0-bearer-tokens/
And the JWT-Bearer sources https://github.com/aspnet/Security/tree/master/src/Microsoft.AspNetCore.Authentication.JwtBearer
If you need ultra-high security, you should protect against replay-attacks by renewing the ticket on each request, and invalidate old tickets after a certain timeout, and after user logout (not just after validity expiration).
For those of you who end up from here via google, you can implement a TicketDataFormat in cookie-authentication when you want to use your own version of JWT.
I had to look into JWT for work, because we needed to secure our application.
Because I still had to use .NET 2.0, I had to write my own library.
I've ported the result of that to .NET Core this weekend. You find it here: https://github.com/ststeiger/Jwt_Net20/tree/master/CoreJWT
It doesn't use any database, that's not the job of a JWT libary.
Getting and setting DB data is your job.
The library allows for JWT authorization and verification in .NET Core with all algorithms specified in the JWT RFC listed on the IANA JOSE assignment.
As for adding authorization to the pipeline and adding values to route - these are two things which should be done separately, and I think you best do that yourselfs.
You can use custom authentication in ASP.NET Core.
Look into the "Security" category of docs on docs.asp.net.
Or you can look into the Cookie Middleware without ASP.NET Identity or into Custom Policy-Based Authorization.
You can also learn more in the auth workshop on github or in the social login section or in this channel 9 video tutorial.
If all else fails, the source code of asp.net security is on github.
The original project for .NET 3.5, which is where my library derives from, is here:
https://github.com/jwt-dotnet/jwt
I removed all references to LINQ + extension methods, because they are not supported in .NET 2.0. If you include either LINQ, or ExtensionAttribute in the sourcecode, then you can't just change the .NET runtime without getting warnings; that's why I have completely removed them.
Also, I've added RSA + ECDSA JWS-methods, for that reason the CoreJWT-project depends on BouncyCastle.
If you limit yourselfs to HMAC-SHA256 + HMAC-SHA384 + HMAC-SHA512, you can remove BouncyCastle.
JWE is not (yet) supported.
Usage is just like jwt-dotnet/jwt, except I changed the namespace JWT to CoreJWT.
I also added an internal copy of PetaJSON as serializer, so there is no interference with other people's project's dependencies.
Create a JWT-token:
Verify a JWT-token:
For RSA & ECSA, you'll have to pass the (BouncyCastle) RSA/ECDSA private key instead of secretKey.
For how to generate/export/import RSA/ECDSA-keys with BouncyCastle, see the project called "BouncyCastleTests" in the same repository. I leave it to you to safely store and retrieve your own RSA/ECDSA private keys.
I've verified my library's results for HMAC-ShaXXX and RSA-XXX with JWT.io - it looks like they are OK.
ECSD should be OK, too, but I didn't test it against anything.
I did not run extensive tests anyway, FYI.