A Session is per browser (determined via cookies), but when does an "Application" start, and end, and how does IIS know know when a request is a part of the same same "Application" instance (if not done via cookies the same way that sessions are)?
"Application" scope is global, and every request to a website shares the same application. Anything stored in the application is visible to all users. The application starts when the first request to the website is made, and ends when IIS stops the website (for example, when IIS itself is shut down, or when the website hasn't been accessed in a while).
Application is said to be start when it is first deployed on the webserver and is available to the users for access. Each time it is un-deployed or the server is shut down the application ends.
The second part is not clear but assuming for determining the application, each application has a root which is unique for all the application that are deployed on a web /app server. So the server can figure that out from the URL being requested.
As such each request is considered as separate and some mechanism like sessions, cookies etc has to be used to club individual requests as a part of single user session.
Related
I'm experimenting with running a .NET Core site in IIS as my own logged in user, because I have written an API that interacts with User32.Dll (moves cursor for example).
I don't care about the security aspect of running a website as my own user.
If I set up the site completely normal in IIS (with identity set to ApplicationPoolIdentity), the API starts and everything works, except it's not my user it's trying to interact with.
At this point I've managed to set the identity to DOMAIN\USER (my user), but when I try to start the application pool, it dies (stops) when I send the first request and just returns 503 service unavailable.
I was hoping running an IIS site as my own local user would be easy, but I've spent probably 2 hours now trying to get it to work. What steps do I have to take? I'm quite lost at this point.
EDIT: I should probably mention, that when I start the application pool, w3wp.exe is not being run. So something is definitely wrong, when I try with my own user as the identity.
We develop an React application with an Express NodeJS backend and this application is secured by an authentication using IBM App ID. Everything works fine on the authentication mechanism if the application is deployed on a Cloud Foundry Service with only 1 instance running.
For performance and high availability reason we need to scale up the number of instances. Unfortunately, as soon as we add an instance, we face problems with authentication. We loop over the authentication screen several times before the authentication succeeds and we can access the application.
For information, we use a Cloudant database to store the session.
Have you ever encountered this problem and how did you solve it?
Thank you for your feedback.
Technically what you are doing is the right thing.
I've encountered these problems before and first thing is usually local session handling - either the default memory store or some file based session store. You should have this covered, as you say you have sessions in Cloudant, but sometimes when you want to enable local developers running the app, you may need to have some switches to control if the shared store is used, but also if http or https is used.
Why http vs https is important, you probably have 'cookie: { secure: true }' which needs to be flip/flopped in that case. Next you might want to http trace the login attempt to see that you don't accidently use another host name than what you begun with. This could easily happen if your CALLBACK url for App ID changes it. These might still not be your reason, and if it is so - then setup that 2 instance environment, save the logs from app servers, http trace from browser and inspect created sessions from Cloudant. There should be only one session created, one url for application used, same session cookie saved in browser. If any of that does not add up - then you need to figure out why not.
I just discovered that azure app services can scale both up and out. For out this means creating multiple instances. So my question is do I need to change my asp.net web app to support this? For example if a user asks to run an async report that runs in background and then comes back later to download the report will it just work? What about security. If a user has authenticated, gotten a cookie, and then leaves the app alone for a while and then continues will it work? Is there any documentation to help.
If your code doesn't support, you can always switch on server affinity. This ensures the request will route back to the same server. However this is not recommended you want any server to respond, rather the same one they started with.
You don't need to change your code, it will just work and its Azure is smart enough to route traffic to the servers for you, so your question about async, yes that will 100% work.
If you use store information in the cookie, it should work without server affinity, but if you use session, then you most likely will need to turn it on (depending on where session is stored - inproc, sql). Here is an article about server affinity https://blogs.msdn.microsoft.com/appserviceteam/2016/05/16/disable-session-affinity-cookie-arr-cookie-for-azure-web-apps/
Hope that helps
The situation
I am writing a Single-Page-Web App (using Angular). Lets call it SPA
Another team-mate is writing some APIs (using Node.js). Lets call is Server
My SPA is to Login to the Server using login/passwd, and do some stuff
My team-mate has decided to use cookies to track the session. Hence, upon a successful login, a http-only cookie is to be set in the web-browser the SPA is loaded in.
The problem
If we put the SPA in the Server's public_html dir, all works well. This, however, makes the SPA as a part of the API code. This breaks our build process, since every version upgrade to the SPA now requires upgrading the API too.
If we host the SPA in a seperate webserver that only serves the static SPA files, I run into CORS issues. Since the SPA comes from a different origin than the APIs it is trying to access, the browser blocks the ajax calls. To overcome this, we will have to set Access-Control-Allow-Origin on the server side appropriately. I also understand that Access-Control-Allow-Credentials:true needs to be set, to instruct the browser to set/send the cookies.
Possible solutions
We create a build process which does a git-pull to the Server's public_html dir every time the SPA gets upgraded. I am trying to avoid this to keep the client and server upgrades separate.
We create a proxy kind of situation, where the Server doesnt store the SPA files, but collects them on-demand from another server that hosts the SPA files. In this case, the web-browser will see the SPA files and subsequent ajax calls from the same origin.
We code the server to set Access-Control-Allow-Origin:* in its responses. Firstly, this is too open and looks insecure. Is it really insecure, or is it just my perception? Also, since we are setting Access-Control-Allow-Credentials:true, Chrome complains Cannot use wildcard in Access-Control-Allow-Origin when credentials flag is true.. To overcome this, we will have to put exact origins (perhaps using a regex) in the Access-Control-Allow-Origin. This may seriously restrict us from distributing our SPA to users in unknown domains.
For a Server API designer, is Cookie based authentication the recommended way to handle Authentication for SPAs? OAuth2.0 and JWT based Authentication seems to suggest that Cookies based Authentication is not right for SPAs. Any pros/cons?
Kindly comment on the above options, or suggest any others that you may have used. Thanks in advance.
I think the issue is that your terminology is confusing. API is not an server, its an application that lives on a machine that can also be a server. If you make a NodeJS API, I suggest you use a Nginx server as a reverse proxy before it. Assuming you want the Nginx server, API and SPA files all on same machine, you can deploy your API to a directory and your SPA to another directory and have Nginx route the requests accordingly.
So I believe solution 2 is way to go. From there you can easily scale by increasing number of instances(if you use AWS) and load balance them or separate your API into its own application server.
As far as authentication. I have always preferred using Header Authorization with access tokens over cookies for SPA or API request. The idea that each request is self contained and does not require a persistent string kept on the browser is more appealing to me, though you can save access token via local storage.
I would go with either solution 2 or 3.
2: you could set both (webpage and API) on the same server (or use reverse proxies) so that from an outside perspective they share the same origins.
3: in the case of an API, the same origin policy becomes less important. The API is to be consumed by clients that are not part of your web application anyways, no?
I would not see any issue in setting a more lax allow origin header. And by more lax I don't mean wildcard, just add the origin of your webpage. Why do you want to wildcard it?
I have two Node.js web applications. One is an Express application, the other is a Restify Application.
Can I use this cookie-sessions module: https://github.com/expressjs/cookie-session in both applications, so that if a user logs into one of the applications, they will also be logged in to the other application?
Please let me know if this is possible, and if so, tips on implementation would be greatly appreciated.
Cookies are stored in the browser and are sent to the specific server that they correspond to with every request made to that server. Cookies from one server are never sent to another server. When a cookie is created, it is configured to either be sent with all path requests on the server or only one specific path on the server.
If your two applications are on the same server and the cookies in question are set for unrestricted path access (which a session-based cookie normally would be), then the the two applications will see exactly the same cookies. If they are on different servers, then neither will see the cookies of the other and there is nothing you can do server-side to cause the browser to send you cookies that belong to a different domain.