How Web Api application start event get fired? - asp.net-web-api

I have made a REST web api and I thought the application_start() event of a web api should triggered once you start the web service from IIS manager, however, what I have observed to my web api is it only triggered by the first web request which reached to the web service. I was wondering if this is supposed to be or I did it incorrectly? Thanks.

That's how it is. From the docs:
Called when the first resource (such as a page) in an ASP.NET
application is requested. TheĀ Application_Startmethod is called only
one time during the life cycle of an application. You can use this
method to perform startup tasks such as loading data into the cache
and initializing static values.
https://msdn.microsoft.com/en-us/library/ms178473.aspx

Related

asp.net Web Api saving user information in session context

I'm trying to create an asp.net web api that calls an external api and gets a response that needs to be stored server side in session context and then later reused in further calls.
What will be best practice for this?

spring boot - how to stop the backend rest api processing after the frontend is closed

I'm using spring boot to create a restful backend application and the frontend is using vue. When someone sends a rest request to my backend application via my frontend webpage, is it possible to stop the backend processing thread after the webpage or the web browser is closed?
HTTP Request cannot be cancelled. General guideline is, the REST calls should be very short. If in case, your REST calls are long running, recommendation is to break into granular calls.
If that is not an option and if you want to cancel a back-end processing, following option can be tried
For every back-end call, return a job id using which server can uniquely identify and return it to the client
Detect browser close
Expose a new Service to cancel based on the Unique Job Id
Handle logic in Server
This will require considerable amount of change!

In grails controller - Session id is different for every request from a single android app

Grails and android App -
For each request (get or post) that I send from an same android app in succession, the session id that i get in a grails controller is different. I expect the session to be the same.
Grails and Web -
if I run the similar request from web browser the session id in the controller remains the same.
Why the session id could be changing, when I call request from an android app to grails server?
Since your api works from the web browser, which is not using ajax. And your Android app is not working. Then it's likely that your browser is NOT using the rest api and your app is. Rest is by default and by implication stateless so it makes sense it's not working from Android. In short: when working properly rest shouldn't be using session ids.
The most common solution is to maintain the state in the client side and transfer it over to the server with each request. You can read more about this here.
On the Grails side, you can just ensure you've got an appropriate rest implementation, as described here.

Repeating logic in each ASP.NET Web API request, where should that go?

I need to store some information in session(or in whatever in ASP.NET Web API) that I need to retrieve in each API request. We will have one api IIS web site and multiple web site binding will be added through host header. When any request comes in for example, api.xyz.com, host header will be checked and store that website information in session that will be used in each subsequent api request when making a call to database. Hope this is clear.
I found a way to handle session in ASP.NET Web API. ASP.NET Web API session or something?.
I know lot more about asp.net web forms where we can override PreRequestHandler. I am looking for similar in ASP.NET Web API where I can have my logic to get database id for api domain(for example, api.xyz.com) and store it in session which I want to access in each API GET/POST request.
Somebody will definitely say by adding session I am making it stateful but REST is stateless. But I wanted to save database trip for each api request. If I don't use session or something similar, I end up repeating the same logic for each api request.
Is there a better way to handle this situation? how?
thanks.
If that logic needs to happen for all requests, you better use an Implementation of delegating handlers.

Redirecting to another web application exposes values stored in session

I have a web application running on JBoss server based on JSF framework.
I need to redirect my request to an entirely new web application running on some other server and on some other machine geographically located.
My doubt is if I redirect the request from my web page to another web application web page will it expose the session parameter at the other end.
I have some very critical information stored in the session and I cannot afford to expose the details to another web application..
Along with the redirect request I would be sending some parameters to the remote web application which will use these parameters for certain mathematical computation.
Can anyone guide me on this?
Is it possible for the other web application to see what is present in the session
No. That would have been a huge security hole throughout the current world wide web. Think about it once again, are you able to see what for example google.com and stackoverflow.com have in its session? No? Then the other web application definitely also can't. All which the web application can see from outside is the sole incoming HTTP request in its entirety.
This problem/question has at least nothing to do with JSF.
If you invalidate the session before the redirect then it doesn't matter if the external web application sees your session cookie. They couldn't turn around and emulate requests on your session anyway because the session is no longer valid.
request.getSession().invalidate();
I don't think this will be an issue though because I doubt that the request header to another web application would include the same session cookie.

Resources