I will be returning to my 10 part series on Modern Web Development soon, but I have a quickie post that hopefully will help some of you.
This is the eighth of ten parts of this blog post. The topics will be:
Oh Facebook…how do you becoming so insistent on integrating you into every website? Well anyway, let’s show you how it actually works. In this post, I’ll show you how to authenticate an app using Facebook.
Web API is a pretty sexy REST stack (though others are cool too). As I’ve been talking about it a lot lately, the biggest question by far is authentication and authorization. There are many options including OAuth, Token-based authentication, basic authentication, and even custom solutions. One option that should be included is to use your existing ASP.NET Forms-Based Authentication.
As a preview to my recently released course on ASP.NET Web API, we’ve released a clip that shows you how to piggy-back on ASP.NET Authentication to protect your Web API interfaces:
Are you in the Louisville, KY area this Thursday? I will be! I’ll be at the Louisville .NET Meetup Group talking about Web API..including Web API 2 that was recently released. The details of the event are:
We will meet on Thursday, November 14, 2013 at Adecco's offices at 101 Bullitt Lane. Doors will open at 6:30pm and the presentations will begin sharply at 7:00 pm. Along with a great presentation, we'll have food and raffle prizes. Be sure to RSVP so we know how much food is needed.
In this new course I build a new web site from scratch. I start out with a Bootstrap template (since my design skills suck) and move through creating content, building a database, exposing a REST-ful API and building a Single Page Application. I wrap it up by publishing the site to Azure Web Sites showing you how to not only get your application up an running in the cloud, but also how to monitor it and handle standard tasks like using your own domain in Azure.
We are very proud to announce that AgiliTrain and Rachel Appel are partnering to present a series of public classes on the next generation of web development. Rachel will be teaching two new courses for AgiliTrain on web development:
I am upgrading my site from the ASP.NET MVC Beta to the RC and I was running into a problem with some of my action links. The issue stems from an old version of the ASP.NET MVC Futures assembly (Microsoft.Web.MVC) that has some cool little niceties that I am using (like lambda's for ActionLinks). The old version of that assembly compiles with the RC but doesn't. If you're using both the MVC RC and ASP.NET MVC Futures, make sure you go get the update here:
In Part 1 of this series, I talked about why I used MVC to create my new venture. In this second part, I will talk about how I implemented MVC.
When I decided to implement MVC, I was very new to it so there is some code in the site that reflects that. The later code and the code I've gotten around to refactoring is much cleaner, but working code is working code.
I am working on a hybrid ASP.NET MVC and MVC Dynamic Data project. To work on it I started with the MVC Dynamic Data project assuming this would be a Dynamic Data Project and an MVC project. As Scott Hanselman recently posted, you can mix and match pretty easily so the code was working but I was missing an important piece of functionality in Visual Studio:
A while back, I decided that this blog deserved a clean coat of paint and since I’m digging into ASP.NET Core, it was logical to re-write it. I wanted more than just to change the look, I wanted to make some real changes to the code and finally open source the code too!
Open sourcing the code required that I do a few things. First of all, I had to change any code that I would be embarrassed by (not a trivial task), but also make it so that much of normal secrets weren’t exposed by open sourcing it (e.g. connection strings, etc.). But as of now, I’ve done it. The source is available and the site is live! I am sure that there are issues with the site, but hopefully I’ll iron those out as they crop up.
Before ASP.NET Core, our world was split between ASP.NET MVC and ASP.NET Web API. In ASP.NET Core that changes to a single model in ASP.NET MVC 6 for handling requests, whether they end up returning data or views.
There is a Web API Shim to bring over old controllers for use in ASP.NET Core. But for new projects (e.g. greenfield), I’d suggest writing your API controllers without the shim.
Like other posts, I am going to list all the changes I found but there are likely more that I didn’t run into. Feel free to use the comment system to add more as you like!
|Using Visual Studio Code for ASP.NET Core Projects (new)|
|Implementing and Securing an API with ASP.NET Core (new)|
|Building a Web App with ASP.NET Core, MVC6, EF Core and AngularJS|
|Building a Web App with ASP.NET5, MVC6, EF7, and AngularJS (Retired)|
|Best Practices in ASP.NET: Entities, Validation, and View Models|
|Front-End Web Development Quick Start|
|Lessons from Real World .NET Code Reviews|
|Node.js for .NET Developers|
|Application Name||WilderBlog||Environment Name||Production|
|Application Ver||18.104.22.168||Runtime Framework||.NETCoreApp,Version=v1.1|
|App Path||D:\home\site\wwwroot||Runtime Version||.NET Core 4.6.25211.01|
|Operating System||Microsoft Windows 6.2.9200||Runtime Arch||X86|