I have followed numerous tutorials and walkthroughs/blogs about the capabilities that Ria Services brings to the table when using Silverlight with ASP.Net. Essentially I am looking for a live working example of the authorization functionality that Ria Services can apparently take hold of from ASP.Net. (Even better if it works with ASP.NET MVC too)
Example of failed to work Ria Services authorization implementation
Navigate to the live demo link on this page....fails
This one may work however I couldn't get it to work on my office computer(strange setup that seems to break code for no reason)
Check here: enter link description here. There is a bunch of posts giving samples. It not exactly what you want but has a walk-through for setting up full authorization.
Brad Abrams has some good information. Also note that the new "Silverlight Business Application" template in the Visual Studio -> New Project dialog has authentication set up already where you can mess around with it without having to figure out how to set it up first.
http://blogs.msdn.com/brada/archive/2009/10/05/business-apps-example-for-silverlight-3-rtm-and-net-ria-services-july-update-part-26-authentication-and-personalization.aspx
C# Silverlight with RIA Services Authentication
Most likely you haven't configured your environment yet. In the machine.config file for the framework version in use, you will find LocalSqlServer defined. You should edit this definition to point at the SQL Server serving up the aspnetdb database that you want to use (and if you don't have one then start by setting up that).
Machine.config is generally in c:\windows\microsoft.net\framework\v2.something\config
For development you have to configure this in the workstation machine.config to make the debugger's webserver use your production authentication database. For production you have to do the same configuration on the production webserver.
There are different paths for 64 and 32 bit framework instances, and if like me you have 32 and 64 bit editions of version 2, 3, 3.5 and 4 then you have eight "root" configuration files. If you hunt them all down and set all of them it will save untold confusion later.
This is from my blog last october:
The Business Application Template for Silverlight comes with a login and register pages. It is very easy to connect these to a ASPNETDB.mdf.
Just add a LocalSqlServer connection string to your web.config file. For example, here is what I use to connect to Sql Server.
It’s almost too easy!
If you are using SqlExpress on your dev machine, it gets even easier. You don’t have to do anything. Just create a new Silverlight Business App and fire it up. Go to the log-on page and register. It will be slow, but in the background, your ASPNETDB was just created and attached, and you will be logged in. If you then look in the Web.config file, you won’t see a connection string anywhere, as the defaults are used for this piece of magic. Of course, a real world connection is going to need it’s own connection string like the above.
Greg
Related
We are developing asp.net website, API and MVC project using Visual Studio. Currently the system we're using are using local administrator account. We are now mapping it to the domain user (normal user). However, certain features are not supported by Visual Studio when we do things like this... importantly..
Debugging applications that a run under a different user account,
such as ASP.NET websites.
Deploying a web application to Internet Information Services (IIS) on a local computer.
Check MSDN Doc here
Note that deploying to IIS is not an issue for us, however the we're unable to debug the application and that is real deal breaker here!
I would like to know how to do debugging for asp.net websites when using domain mapped normal user.
I know this is not a programming related question. However, seems like most of dot net programmers are affected with this and I don't know where to ask for help, so posting it here. (Suggest if any other site is suitable for this!)
Thank you for your help in advance.
The simple answer, as mentioned in that MSDN document and this SO question, is that you can't.
It might be possible to do it through roundabout ways, such as changing the credentials that the IIS worker, application pool, and related processes run as, but even if it were possible, it wouldn't be supported, and most likely wouldn't be worth the effort. Here are two very old articles that deal with the topic:
https://msdn.microsoft.com/en-us/library/aa289173(VS.71).aspx
http://jameskovacs.com/2006/03/16/debugging-as-a-nonadmin/
It may be more feasible if you're able to run your application in an OWIN (Wikipedia) container running in an alternate (to IIS) host.
I'm brand new to C#/.NET
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. If there are libraries to help me do routine stuff like constructing the HTTP request, parsing the header, ect - then cool. But I don't want a super opinionated framework that tries to do everything under the sun.
Why do I need IIS at all?
Addressing your points in reverse order, first - why do I need IIS?
The answer is, maybe you don't. If you are doing a simple listener that won't be exposed to the public internet, then you don't need it.
If you are doing a web application that needs to scale, be robust and easy to manage then it can help you with:
Logging
Operating in a multi-server environment for scale/high availability
Handling multiple requests in an isolated way
Serving multiple applications from the same host with sandboxing to ensure each application has guaranteed resources (memory, CPU)
Application lifecycle management
IP address restrictions
support for FTP, CGI, WebDAV
URL rewriting
Response header manipulation
Failed request tracing
Protection against some DoS exploits like slow HTTP attacks
Etc.
In short, it is an industrial strength, real world web server that will keep your application up reliably in a hostile world and scale as your application grows. it is certainly overkill for some cases if you don't need this kind of scale/high availability/management capability. In those cases you have the option to self host ASP.Net in a Windows Service or even a console app. This might sound complicated, but it has been made pretty simple by OWIN - Open Web Interface for .Net. This is an abstraction of the interface used by Asp.Net to communicate with its hosting server.
There is a very good tutorial on how to self host web API in a console app here
http://www.asp.net/web-api/overview/hosting-aspnet-web-api/use-owin-to-self-host-web-api
It does exactly what you ask for in your comment:
You create a console app project
You add references to the right assemblies (the tutorial uses NuGet to download the assembly packages)
You code up your web operation logic
You compile
You run the resulting exe
That's it!
On your second point about ASP.Net - it is a framework that has gone through a lot of evolution trying to keep up with very rapid changes in the web development world. This meant it got a bit bloated and lost some of its coherence, but recently the developers have been focussed on making it more lightweight, more modular and simpler. Scott Guthrie summarises it in his blog:
http://weblogs.asp.net/scottgu/introducing-asp-net-5
Why does ASP.NET have so many different choices of projcets? (Web Application, Web API, Web Site, MVC ect). I just want to listen on a tcp port, and a way to send a response. etc...
Because each project has its own purpose.
If you want to just listen on a TCP port then you could go learn Microsoft's Katana OWIN (but I highly doubt if this is what you want).
Katana OWIN
Briefly going through each projects purpose:
"Web Application" actually opens up another window and lets you choose from the following:
Web API is for exposing RESTful services or JSON data.
Web Forms is for making web pages that use Web Form components.
(A bit like Windows Forms, but Web)
MVC is for making Model-View-Controller web applications. This is where you build components with a separation of concerns. Model for data. View for what the user sees. Controller for controlling how your page behaves.
Why do I need IIS at all?
IIS is for serving .NET applications.
Without it, it would be quite hard to serve .NET applications.
I'll start with 2 then move on to your first question. IIS will run whatever the .NET web service you need, be it a monstrous WCF service, an ASP.NET application or the most basic http handler.
To my knowledge, ISS is the most straightforward way to use .NET web services. If you are used to PHP, it's basically LAMP or WAMP for .NET, which means it is sort of necessary. There are alternatives, as Mike Goodwin points out, but I have to admit I am not familiar with those third parties. Since replacing a layer for another doesnt mean much, I would stick to the "normal" procedure.
Since you dont want the framework to do a truckload of operations for you, your best bet might be along those lines:
Create a basic ASP.NET projet
Remove the default ASP.Net page because it seems you dont want it
Add a Generic Handler to your project. This will result in a myFile.ashx, which handles http requests and let you build any response you want
Of course, if you dont want to bother with IIS configurations, you'll need someone to setup an URL on IIS and map it against your handler repository.
EDIT:
"Abstraction layers" would be the very definition of frameworks, for good or ill, so you're stucked with it.
Now, since you have a low level background a not-so-intrusive way to work with the .NET web services would probably be the three steps I suggested earlier. You are still stucked with IIS though, in order handles the communications (i.e. manages sockets/requests). That's the way the framework works.
STILL, THERE IS HOPE. If you have complete control over your server (which is not my case, some other IT team manages the web servers), you certainly could build a windows service that listens to some socket and work the requests accordingly. It is a most unusal solution if you want to serve web pages, but would work rather well if you only want to push some data through http requests. If you go down this path, I suggest you take a look at the System.Net namespaces, you'll find some classes like "Socket" there. Combined with a console application or a windows service, you could work something out.
One of my coworkers is former microcontroller designer, I know exactly what kind of feeling you have towards the .NET framework. You'll go through some frustrations at times, but most of the time there are work arrounds. Feel free to request more details if you need some.
I'm trying to build an ASP.NET MVC5 site for intranet use. I need to install it on a server and connect the login form to use Windows credentials for users logging into the site. Its a large corporation with several levels of IT and Security to get through for anything 'special', so I'm looking for simple and no change requests if possible.
I've been searching and reading online for several days, run through the Visual Studio wizards, tried various configurations, researched the IdenitityStoreManager and IdentityAuthenticationManager interfaces ...
I can easily build the site to use individual accounts, which seems to have the behavior I want, except that it wires in a database. I don't want the database, I want it to use the Windows/Domain credentials for access.
I've found lots of info about hooking up to AD/ADFS in Azure, and even a little for On-Premises, but it seems far heavier than I want. I'm guessing I can do what I want in a little bit of configuration magic, but ?
Are there any good examples or blogs available for this specific usage ?
Google found lots of answers
For example this one is good enought, it's about MVC 3, but it's the basics of this subject
Main configuration is happened in web.config file:
<authentication mode="Windows">
</authentication>
Can I convert a non-MVC asp.net application to be Azure compatible ? Or If i want to create an Azure web application, should it be MVC one ?
The other answers answered your question about converting your app to MVC for deployment to Azure (you don't need to).
If you're creating a new web application and go with ASP.NET MVC (which I'd recommend), just remember if you go with MVC3, you may have to make some of the MVC3 DLL's CopyLocal for your deployment, as it won't be part of your web role instance. At least that's how I still understand it. The 1.4 SDK of the Azure SDK doesn't have a MVC3 Web Role template yet.
See this post on steps to get your MVC3 app Azure-ready.
Hope this helps.
You may take a look at the following blog post for migrating an existing ASP.NET application to Azure. It should not necessarily be an ASP.NET MVC application. Any ASP.NET application will work.
azure has 2 roles
1. a webrole
2. worker role
web role is nothing but an asp.net app. so no need to convert it into an MVC app just any asp.net thing will do fine
Yes, you can. But you need to be aware of certain limitations too, none of which were mentioned in the answers already given:
Your application should be stateless, unless you are running a single instance (for most apps 99,9% reliability is OK, but there are some where you want 99,95%, so you need at least two instances + it gives you additional benefits of a load balancer, etc.). The reason for this is that if you have more than one instance, the load balancer will deliver the request to a different instance. You can use AppFabric Cache to solve this.
You don't have a file system - this is not entirely true, but in reality you should never rely on having local files. All you image uploads (e.g. user profile pictures) should be uploaded to a blob storage and linked to there. How you do this is another matter, and one that can be approached differently depending on the architecture of your existing application. You can get away with files, by using Azure Drive, but it's slow as hell.
No Event Log / RDP - this is also only partially true, but you should rely on other ways of getting diagnostics information from your role. While you can RDP to your role instance, there are better ways (e.g. Azure Diagnostics storage).
Database should be chosen carefully. Sure, you have SQL Azure available, but it's expensive (1 GB = 10 USD/ month). If you can get away with stuff like Table Storage, you may save on some costs. Again, this depends a lot on the architecture.
As for the second part of your answer. MVC as a pattern is nice. It saves you a lot of time, it's much more adapt for the Web as WebForms ever will be. The event based system was designed for Desktop applications, and it was forced onto the web. However, going to Azure does not imply a requirement to go to MVC. What I suggest you do however, is treat it as a nice jump-start opportunity to look into MVC and see how it could help you write your apps better & faster.
As with any other case involving architecture of apps, it depends. If you used common patterns (e.g. IOC, Repository), you will have a really easy time moving any app to Azure.
I need to quickly wrap some security around an existing ASP.Net 2.0 web app. After thinking about it for a moment, I remembered that Microsoft created that Membership and Roles paradigm a couple of years back, and that Visual Studio could essentially create everything for you.
Thus I forged forward using the built in ASP.Net Web Site Administration Tool and created a simple little security framework around the application. After setting all of the options, Visual Studio created a nice little SQL Express DB called ASPNETDB.MDF right under the newly created App_Data directory of my website. This works great until you deploy it.
After trying to push this app to my DEV server I realized that it's not going to work unless you have SQL Express installed on the hosting machine. Worse yet, I figured that there's essentially no way this would work under a load balanced environment considering the DB itself will only be isolated to one of the N nodes.
Rather than work to script out the DB and shove it into my existing SQL box...I figured I'd ask the StackOverflow if there is a better solution for simple yet secure ASP.Net websites.
I'd love to maintain the existing model yet have the database become a local, or flat-file DB baked right into the application. For the time being I'm even fine with deploying the flat file with each user or role change to counteract the load balanced sites in PROD.
Is there not a way to create some sort of similar setup with a flat file? I thought that was the point of the App_Data folder?
You could use a custom Role & Membership provider that supports a flat file, like XML. Here is a link to a XML Membership provider, I've seen similar implementations for Roles.
XML Membership Provider
it's not going to work unless you have SQL Express installed on the hosting machine.
Not necessarily. If you still want to use default membership/role providers you can either have the DB server on the hosting machine or have one instance of the DB as a separate server (just change the connection string for providers).
Worse yet, I figured that there's essentially no way this would work under a load balanced environment considering the DB itself will only be isolated to one of the N nodes.
This statement is not really correct in this particular situation.
With load-balancing you will not have isolated database, but rather a separate database server.
I'd love to maintain the existing
model yet have the database become a local, or flat-file DB baked right
into the application. For the time
being I'm even fine with deploying the
flat file with each user or role
change to counteract the load balanced
sites in PROD
If you say that application with proper SQL DB will not scale, I do not understand how flat-file storage can.
You still can keep local SQL Server database and it will work as long as you take responsibility of maintaining the database consistency across different nodes.
In your situation, I would personally use default membership/roles provider as you do now.
But when deploying, just change the connection string to the proper database server.
You will need a database for other stuff anyway, so why not use the same database for all data withing the application (including membership/roles).
Regards.
I found an excellent solution to this here...http://aspnetxmlproviders.codeplex.com/. Using the dynamic XML you can hack out a simple provider based security model in no time flat.