I develop web and mobile applications for my customers. In my current architecture, many resources are shared between the web access and mobile access. An aspx page can be shown on web and be called to a web view in a mobile app. My question is :
What is the difference between WebOperationContext.Current and HttpContext.Current object?
From my understanding it is the same object, but I noticed that WebOperationContext.Current is null in some cases and I don't understand why.
WebOperationContext is typically used in a WCF REST method so that method can access the incoming request and outgoing response.
HttpContext is typically used in an ASP.NET WebForms page or web method for ASMX Web Service, when incoming request and outgoing response can be accessed.
They are designed for different project types (WCF REST/ASP.NET WebForms) so you should not use them in a wrong project type.
About when the value of .Current is null, that's even more complicated. Even if you are calling this property in the correct project type, you need to make sure the call is made on a proper thread. Only on the thread that handles the request (which also sends out the response) you can access the current context. On any other threads (background threads, or new threads created by you) you get null. This has been known for years but beginners still get it wrong sometimes.
Related
I am trying to implement role-based authentification to the REST WCF service . I read a lot of information on this theme but didn't got a clear understanding of what I have to do.
I understand how to restrict an access to the service using the [PrincipalPermission] attribute but don't know how to check whether the user belong to the certain role or not.
Therefore I will be very grateful if somebody can direct me to the right way (e.g. make a roadmap what should I do to achive this goal).
Let me describe this situation. I have a remote services which hosted on the server A and ASP.Net MVC client hosted on the server B.
All of these rest services has an access to the database where I can read an information whether the user has access to the service or not.
OK, Tequila, IMO what you really want, based on your description, is a normal, REST WCF service with a Login(ID as string, PWD as string) method that (perhaps) returns a SessionID. This Login() or SessionID() check method would then preceed access to all of your other methods. And since it's a webHTTPBinding -- effectively a stateless web service -- you'll need to check the SessionID or ID/Password before each request is processed.
So the workflow would be something like this:
1) client sends Login() request to host
2) host checks ID/Password against DB, creates SessionID in DB that times out after x hours, forcing new Login(). SessionID is returned in response to client,.
3) In all subsequent requests, client must provide that SessionID. That SessionID would be checked on the DB, returning stored information about the client (Role, name, ID, address ... whatever is useful) before the remainder of the request is processed.
There are methods for authenticating users BEFORE the request gets to your working code (like client authentication using Forms or client certificates (see http://msdn.microsoft.com/en-us/library/ff405740.aspx)). This shifts the Login() / SessionID check to a method executed BEFORE the request hits your main program, but the steps are basically the same.
And since passing ID/Pwd in clear text over the web is a no-no, you'd want to implement SSL on your web service (see http://msdn.microsoft.com/en-us/library/ff650785.aspx)
Everything I've describe is basically platform independent, so if you'll have iOS or Android clients, there's nothing in what I've described that would prohibit those OSs from successfully interacting with your web service.
Good luck.
While explaining concepts of ASP.NET MVC to my students
MVC is stateless. It is built on top of another stateless
protocol - HTTP and HTTPS
But one student interrupted and asked,
You tell that the MVC is stateless
Stateless protocol never cares if the response comes back or not from
the server. But, in ASP.NET MVC framework, you make a request and wait
for the response. Since you wait for the response, it should be called
as a stateful service. How come you are calling it a stateless service
then?
I really got stuck up and wondered what to answer to this question.
Any ideas?
MVC is not stateless, HTTP is.
HTTP being stateless doesn't mean it is fire and forget. The client does wait for the response. It is stateless in the sense that two successive requests have no relation whatsoever.
State can be emulated using sessions, for example using cookies.
The assertion in the question, purported by the other student it wrong. A stateless protocol like HTTP sure does care if it gets (or never gets) a response!
[A stateless protocol] treats each request as an independent transaction that is unrelated to any previous request so that the communication consists of independent pairs of request and response.
Of course, MVC isn't even a protocol .. but the same notion can be extended. It is "stateless" insofar as all the information is encoded in the request and response as a "pair". In practice, most usages are not truly stateless.
Please keep in mind, that there are a lot of different implementations of the concept of a model-view-controler architecture. There is no "correct" MVC. ASP.NET MVC cannot be is not a "perfect" implementation of the model-view-controler pattern!
Otherwise of thinking of stateful/stateless MVC. MVC can be understood by thinking of responsibilities:
The View is not allowed to change the state of the model directly - only through the Controller. The view can still have some direct access to the Model although only for viewing (or by having a copy that isn't the official Model).
The Model should live in its own universe and not have any reference to controllers or to views.
The Controller controls the state and access to the Model.
How they all interact with each other, can be implemented very differently (based on the platform for example) ...
MVC is not a protocol is a software architectular pattern.
On the other hand, HTTP is a protocol.
In nowadays the MVC pattern is very popular among many web frameworks. These web frameworks and the rest of other web frameworks are used for the development of web applications.
In the context of web applications HTTP is an application protocol that is used from browsers for their communication with the servers that host web applications.
Indeed the nature of HTTP is stateless. There isn't anywhere in HTTP the concept of state. For this reason, in many web frameworks, there are different ways through which we try to implement the concept of state. For instance in ASP.NET Web Forms the ViewState was developed for this reason.
That being said, MVC has nothing to do with the stateless nature of HTTP.
In a self hosted ASP.NET Web Api, how can I:
Detect from a class if there's an "ambient" web api context. This is needed to avoid passing in metadata information on every service call. I'm looking for the equivalent of
System.Web.HttpRequest.Current != null
How can I attach metadata information associated with the current request. Again some of this metadata is just so prevalent that including them on every method and calls is way too painful. Think transaction, multi-tenant architecture and credentialings. I need a way to make this sort of information flow through between requests without cluttering the code.
In another word I also need the equivalent of this as explained here:
HttpContext.Current.Items["user" + X.ToString()]
I think I can still access them, as long as the WebApi is hosted on IIS, but I have got these self hosted and I need a way to keep track of the ambient UoW information - how can I do so?
A few notes:
I have also contemplated using per request DI and injecting a
request context into the managers, there are however a ton of legacy
code that wasn't set up for that (some of which are static) and I
don't have the guts to blow up production by doing such a major
refactor.
I have also used a thread static, static variable - the problem with such is that the thread gets recycled, and the process hosts multiple services, some of which aren't even WebApi... so sometimes my managers thought it's handling a WebApi request when in fact it's serving a WCF one.
The HttpRequestMessage instance has Properties dictionary that is intended for holding arbitrary per-request context.
Looking for ideas. From within a web application (app #1), I need to call another web application (app #2), allow web app #2 to PRESENT FORMS TO THE USER, do some work, and then receive a result or return value into the original web app. The apps must be completely separated code bases. More than likely app #2 will need to be contained in a popup window but that is not entirely clear as of yet. There is a possibility that the single window may navigate to the second app. The apps are currently using ASP.NET and C#.
I originally thought of sending a "callback URL" to app #2, and allowing app #2 to post the result to app #1 through that URL, but then someone mentioned the need to do this as a modal window and NOT app #1 to navigate away from the calling page. On the other hand, if the receiving page was maintained on the back end, then it should always be possible to simply have the original app check for a session variable (or similar) since, as long as the browser for app #1 is not closed, the session content would still exist.
Thanks, in advance, for taking the time to respond.
If you want to communicate between two web applications, I would set up a Web Service interface in the second application. Then your first app can send "requests" to the Web Service that lives in the second app, and receive a response back.
MSDN has a lot of detailed information about this topic here: XML Web Services Using ASP.NET
The more specific places to get you started would be the guide to using Visual Studios web service creation wizard, and the examples of how to call a Web Service method.
This Stack Overflow answer has another way to call Web Service methods that might be more relevant to your use-case (calling via the URL).
I have a webservice with a .asmx extension which points to a class in my web application. After adding some code to output a debug log on application startup, I can see a new debug log is being created every time a user visits the page.
I was hoping that I could configure this web service to only ever use a single instance.
Meaning, when the first user visits the site it creates an instance of my webservice, and then all requests after are routed through that same class, sharing the same state.
Is this even possible?
Web sites are stateless in nature. Meaning, each request is generally unrelated to any other request.
That said, you could set the log as a static variable in your global.asax file. Be aware of threading issues.
Alternatively you might look at Elmah.
You seem to have a number of problems.
First of all, the ASMX technology is all but obsolete, and should not be used for new development. WCF should be used instead.
Next, yes, you can have multiple calls to the service share the same instance of your class. However, you'll have to prevent simultaneous access to this class unless it is thread safe. You should expect multiple service calls to call into the same class instance at the same time.
Finally, ASMX does not support singleton web services. The best you can do is to have multiple service calls all share the same object (carefully locked).