Sorry for the lack of knowledge here guys by the agency I work for has inherited a site built on windows server with ASP.net.
We're having problems with the user login system. The basic story is when a user requests an account an admin must approve it. If the admin rejects the user application the user can then still login by using the forgot password option.
My initial reaction is bad logic in the code but we've had some ASP guys take a quick look and were unable to reproduce the problem. Because of this they've suggested it might be some kind of caching issue. If so is there anyway to set the sever to reset it's cache every hour or so? or any other recommendations on this are also welcome. Sorry for the complete lack of code examples but a scenario is all I can offer right now.
Cheers.
If you can't reproduce it then there is no problem; although I concede there might be a caching problem. But without knowing more about your application all I can suggest is to grep your source code for references to the System.Web.Caching.Cache class (usually accessed via the Page class directly if not by HttpContext.Current).
Removing the idea of a cache being responsible, I think it's just a case of bad coding of the forgot-password feature. I guess is the forgot-password feature resets some kind of "account disabled" flag and that's what allows the user to get in.
The ASP.Net caching class has an iterator for the cached items, and a method to remove an item. It's difficult to host long-running processes in IIS -- because "idle" worker processes get killed -- so you can't just run a timer. But you can use the IIS auto-start feature, combined with a persistent store, to run your "nuke the cache" method every hour.
With that said, I can't see how this is a sensible solution to the problem -- I hope the plan here is just to help isolate the real issue.
Related
I want to build an application to email field workers in our company when their passwords have expired. I'll be using some type of C# application while communicating with Active Directory.
I also want to ensure that users do not get emailed every single day/night, as this sounds a bit obnoxious. The idea I have is to create a web application with no UI, and have a global list of emailed users that never gets reset, just gets updated (user gets added when they are emailed, and get removed when their password is no longer expired). So I'll fill that list with a user object containing their samaccountname and the day they were emailed. If they are in the list, I don't want to email them again.
However, upon doing some reading, I found that multiple sources said that having a non-interactive web application to be executed on a schedule isn't a good way to do it. Instead, it seemed people were fond of Windows Services, which is something I don't know a lot about.
What would best practice to implement something like this? My ideas might also be completely off. Thanks for any insight.
Edit: New idea - Perhaps using an SQL table would be a better idea than a global list.
Yes, you're absolutely right about the storage, sql or nosql should do the job.
My advice is to store the the information you have describied in some database, this way you will have secure and long-living storage about the data (scenarios like power-cut, network drop or even simple restart of the server won't lead to loosing the information about the send emails).
Using the task scheduler with simple console application will be just fine. It sound more close to your needs (executing checks and notification at periods).
I have a large web application in ASP .NET (not that the technology matters here) that does not currently have a way to be locked down for maintenance without current users losing their work. Since I have not implemented something like this before, I would like to hear about some of the standard precautions and steps developers take for such an operation.
Here are some of the questions that I can think of:
Should each page redirect to a "Site down for maintenance" page or is there a more central way to prevent interaction?
How to centralize a scheduled maintenance such that user operations lock down before the site is locked down. Thus preventing loss of unsaved work.
The application is data-driven and implements transaction scopes at the business layer. It does not use load balancing or replication. I may be wrong, but it does not 'feel right' to have the BLL handle this. Any suggestions or links to articles would be appreciated.
One way to make a maintenance page is to use the app_offline.htm feature of IIS. Using this feature you will be able to show the same html page to all your users notifying them about the maintenance.
There is a nice post here in StackOverflow about it. ASP.NET 2.0 - How to use app_offline.htm.
Another thing you could do is to notify your users that there is a scheduled maintenance so that they also be aware and stop using the application.
That all depends on the time you need to upgrade your application. If the upgrade is to upload the new files and take not more that a minute or two, its most likely that your users wont even see it.
A non-answer answer that may be helpful: design the application so that it can be upgraded on the fly transparently to its users. Then you never have a maintenance window that users really need to worry about. There is no need to lock down the application because everything keeps working. If transactions get dropped, that's a bug in the application because there is an explicit requirement that the application can be upgraded with transactions in progress, so it's been coded to support that and there are tests that verify that functionality.
Consider as an example Netflix: does it have a locked down maintenance window? Not that the general public ever knows about. :-)
i have developed a web application C# in Asp.net. it is a kind of intranet app. There are some pages which are used for Crud processes. But every things is ok in local test. Press F5 :
1) GetList() -> OK
2) AddNew() -> Ok
3) Save() -> Ok
But multi user (Real world) is angree this error :
object reference not set to an instance of an object
BUT every thing is ok in local. User said that "Yes every thing is ok in 2-3 hours but after afternoon. i see error: object reference not set to an instance of an object"
i have 2 scenario
that problem is GC.Gc can dispose my instance to make above methods!
Session to timeout
Please think 2 scenario; how to extend the life of instance or session or control GC or any other best opinion? Thanks...
Best Regards...
You have to be able to reproduce the problem, then use breakpoints / tracing to figure out where the error is. It is not necessarily related to session timeout, but it could be, if your user has not been using the app for 15 minutes or more.
The Garbage Collector does not collect anything that is still in scope, so that cannot be the problem.
So, make sure you can reproduce the problem, you'll probably have it fixed quickly (and if not, report back your findings here!)
You can set the Session timeout from web.config:
<sessionState timeout="30"></sessionState>
where timeout is in minutes. Learn more about configuring the sessionState element here.
It's definetly not the Garbage collector as it will not collect memory that is referenced.
The only way you will be sure that the reason is "session expired" or not is to:
Find where the error is
Detect the reason for it
In your case it might be a little difficult to do debugging since the user is experiencing the error most likely on production. So you need some type of logging system. If you like classic logging then you can use log4net. If you like to be notified by email about exceptions etc. you can use Elmah.
If you haven't set a timeout for your web application, it will fall back to the default of 20 minutes. If the user has left the screen idle for more than the default time, the session will time out and you will probably get the error you user is experiencing (the infamous yellow screen of death).
You can extend the session state in the web.config, see the following link:
Setting the session timeout property
#misha has given an example of how to do this.
I would also try what #Roy suggested and try and reproduce the error in the dev environment.
It can be session timeout. I advice to add some logging into Global.asax Session_End event to see when it happens (if at all). This could help you with this error. Putting logging into many places is generally helping to debug difficult or intermittent problems. If you want to go serious about logging check log4net (free) library. Quite powerful.
This question may be easy and the answer obvious, but I can't seem to be able to find a solution right now.
I built an application which has a big flaw in it. In a property of my User class, I check to see if the user subscription is expired. To do this, I compare the ending date of the subscription with DateTime.Now:
return (DateTime.Compare(DateTime.Now, subEndDate) > 0);
It doesn't take a genius user to realize that all it is needed is to change the Windows date to an earlier one, and then the application won't expire at all. So I think that comparing to DateTime.Now should not be done, is there a better method that I could use in order to validate a subscription date?
Thanks.
Regards,
Call a webservice or check a database to determine if the subscription is still active
Does this actually matter? If your product is purely web based the only time you have to worry about is your server time. If the server time is able to be altered without your consent you probably have larger problems to worry about.
If your product is desktop based, then how much protection do you want build in? If you just want to protect against your casual user the solution you have is probably enough. If someone is determined to pirate your software then they will probably be successful. If you want to make it harder for these users one solution would be to keep a log of all the times the application has been run. This way you can get an idea of they are playing with the clock.
Maybe you could extract the subscription expiration logic out of your client program and put it into an external service, then your client app could connect to a different server and retrieve expiration details based on a user parameter passed in?
There are several NTP servers out there which you can use for free... they return the exact time and your casual user won't have a hand in manipulating those... to access them you have several options - though none built-in:
http://dotnet-snippets.com/dns/simple-network-time-ntp-protocol-client-SID571.aspx
http://www.codeproject.com/KB/IP/ntpclient.aspx
http://www.codeproject.com/KB/datetime/SNTPClient.aspx
http://www.rebex.net/time.net/ (commercial)
I am in need of filling the Windows Security Event Log to a near full state. Since write access to this log is not possible, could anybody please advise as to an action that could be programatically performed which would add an entry to this log? It does not need to be of any significance as long as it gives an entry (one with the least overhead would be desired as it will need to be executed thousands of times).
This is needed purely for testing purposes on a testing rig, any dirty solution will do. Only requirement is that it's .NET 2.0 (C#).
You can enable all the security auditing categories in local security policy (secpol.msc | Local Policies | Audit Policy). Object access tends to give plenty of events. Enabling file access auditing, then set audit for everyone on some frequently accesses files and folders will also generate lots of events.
And that's normal usage, and that includes any programmatic access to those resources being audited (its all programmatic in the end, just someone else's program).
Enable Login Auditing as Richard mentioned above. Success or Failure is dependent upon how you handle step 2:
Use LoginUser to impersonate a local user on the system - or FAIL to impersonate that local user on the system. Tons of samples via good for viable C# implementations.
Call in a tight loop, repeatedly.
Another approach you can take involves engaging object access, and doing a large number of file or register I/O operations. This will also cause the log to fill out completely in an extremely short period of time.