I have a web application built by ASP.NET Web API and the database is Oracle.
When I published the site on the IIS and run it, I recognized the following:
I found many records in the view DBA_AUDIT_SESSION and that's records LOGOFF/LOGON in the order.
After that, I let the site open for a while on a tab in the Chrome Browser without any interaction from me and I found many records LOGOFF, then return to the tab and open a page included it, and I found new records was generated on that view but with Action LOGON.
My question is:
1-That's normal or my application has an issue?
I analyzed that, but maybe I was wrong:
I think when the site run using IIS, all the old sessions will be LOGOFF, and after the application run on the browser, new sessions will be generated, and when the application sleep "without any interaction" the session will be LOGOFF and after return to the application and ask for a page included it, the application will ask a data from the database using an API and that connection will register as LOGON action.
Another question:
I check the main view DBA_AUDIT_TRAIL and I found the Action LOGON come with comment_text explain the Authentication process, and in my case, it comes with:
Authenticated by: DATABASE;
My question is in every LOGON action the port changed, why that?
Establishing a database connection is a pretty expensive operation. Ideally a web application should be using a connection pool, so that you create create pool of database sessions initially and they remain there for the life of the application. The app tier will ask for a connection from the pool as it needs to interact with the database.
So utopia is to see an initial set of LOGON records and then no LOGOFF records until your shut the application down.
Related
I have a web application developed in asp.net
The application has a "logon" portal where I record users logging on. However, I don't really know when they have exited the web application as they could just shut down the browser, rather than using the "logout" option. As IIS keeps track of session variables for a finite period when users logon, I thought a really useful option would be to use my ASP.net application to interrogate IIS for the value of all session variables, thus telling me who is still active via their session variables.
This could be very useful when it comes to dropping in an upgrade to the website and generally looking at the use of the site.
Thanks
session object. But it only tells me about the current user.
I have a web application (.net VB code) that utilizes session variables to store the username (here login name) and the profile (admin/client), authentication is handeled by asp membership. The application then relies on these session variables on the load events. This application has been running fine for a couple of years. However, recently users complain about occasional error messages after logging in and attempting to load a new page that needs one of these variables. It happens most frequently Chrome, but also IE and Firefox.
Users that experience the error need to log out and clear the browsing history, after that it works again. The error is not easy to replicate - I was able to trigger it on my machine 'violently' using the 'back' button a couple of times that eventually tripped it - then I had to clear my browsing history to get the application to work again.
What might cause this to happen?
the session gets set on the load event of the 'login' page with 'Session("Type") = "Admin"' and subsequent pages check for the value of Session "Type"
I understand that I could use a cookie instead, but I chose not to for security reasons. Could this be prevented using a cookie instead? or do I need to use the membership.getuser method to get the username and then look up the values in the database? That does not seem efficient.
Ideas?
FYI, the ASP.NET Session ID is stored in a cookie that travels back and forth with each request/response. The actual session state values for a given session are not stored in cookies ... they are stored on the server only. They could be stored in memory, or in a SQL database, depending on how you've configured ASP.NET Session State.
But Session State can get destroyed for a variety of reasons. IIS might suddenly decide to restart your Application Pool, for example, in which case all your Session State would be gone.
Basically, you need to write your web app to always handle the possibility that Session State may be empty. If it is empty, then you probably need to redirect the user to the login screen to enter his credentials again.
Clearing the browsing history should have no effect, so I can't explain why that would help get past the problem.
In my ASP.NET project, I am using Forms authentication. My main.master using LoginStatus control and web.config is set up for "Forms" authentication mode.
Before I log in, the control shows the text as "Login." After I log in, the control shows the text as "Logout." This is expected. However, after clicking around on a few links within the site, the control suddenly starts showing "Login" although I am still logged in. The session is still alive as some of the pages I visit dumps some session information.
Would appreciate if something can point me in the right direction. Regards.
If you are trying to redirect after setting a Session variable using
Response.Redirect("YourPage.aspx");
this may be causing the session token to gets lost, try using the overloaded version of Redirect:Response.Redirect("~/YourPage.aspx", false);
Another problem also may be miss configuration of application pool. If the application pool is configured as a web farm or a web garden (by setting the
maximum number of worker processes to more than one) and if you're
not using the session service or SQL sessions, incoming requests will
unpredictably go to one of the worker processes, and if it's not the
one the session was created on, it will get lost.
The solutions to this is either not to use a web garden if you don't need the
performance boost, or use one of the out of process session
providers.
For more information you can check the link of the original article below: http://weblogs.asp.net/bleroy/Don_2700_t-redirect-after-setting-a-Session-variable-_2800_or-do-it-right_2900_
Ive created a app in asp.net using c# that needs to create folders on a number of network shares. Ive configured the app pool account to use a domain account and given that domain account the correct permissions to the network share folder. When i run my code im getting the following exception. Any ideas?
Exception: System.ComponentModel.Win32Exception
Message: Logon failure: unknown user name or bad password
You should create an account on the network that has the relevant access to that share and then set your application pool to use that identity.
This way, all requests from your application will appear to be that user.
Take care with this approach, however, as if anyone changes the password to that account, you will need to update it within your IIS
OK seems I've been a bit of a chump. Seems there was some code I wrote (cant remember doing it) that impersonated the account I had set for the custom app pool but with the old password. Simply commented out the code and it now works as expected. Note to self!!!!!! Must read stack trace more carefully in future.
Apologies for wasting your time
I am trying to call an old VB6 dll (no source code available) from an ASP.NET project. The dll connects to a server using windows authentication, so I need to call functions as a specific user, not NETWORKSERVICE as it is now.
This would preferably be determined at call time, not load time because I am impersonating the remote user and would like for this to be the user calling the functions, not the application user and not NETWORKSERVICE as it is now.
So, theres the browser running as USER, connecting to the application impersonating USER, calling the dll as USER, but the dll is trying to connect to a remote server as NETWORKSERVICE, not USER.
Is it possible to make this dll connect to the remote server as USER? Or, if nothing else, connect as the application user?
Edit:
Impersonation is done in code by calling Impersonate() on the remote user's WindowsIdentity. The company I work for has a custom SecurityPrincipal and SecurityIdentity so it's kind of weird how I have to go about getting the WindowsIdentity (it's a little more in depth than User.Identity), but I have used this method before successfully and have verified that System.Security.Principal.WindowsIdentity.GetCurrent().Name
is the correct user during the impersonation.
I would first try to find out how the DLL is connecting as a different user (Process Explorer can help with this). Is it possible that the DLL is communicating with a service (or some other process) which is running on the box which is logged in as NETWORKSERVICE? If so, you can change that service to run as a different user. Just grasping at straws, hope you figure it out!
I did eventually find the problem (which just lead to other problems, but anyway) it turned out to be I was missing an AspCompat="true" on my page. Actually the problem was that I was using a "Handler" and not a "Page". Handlers do not have the STA abilities that Pages have. What was happening was every time I tried to access the COM component, there would be a thread switch (impersonation lost) since the application is running in an MTA and the COM component must run in an STA.