eval()
is not necessary. This will work fine:
var date = new Date(parseInt(jsonDate.substr(6)));
The substr()
function takes out the /Date(
part, and the parseInt()
function gets the integer and ignores the )/
at the end. The resulting number is passed into the Date
constructor.
I have intentionally left out the radix (the 2nd argument to parseInt
); see my comment below.
Also, I completely agree with Rory's comment: ISO-8601 dates are preferred over this old format - so this format generally shouldn't be used for new development.
For ISO-8601 formatted JSON dates, just pass the string into the Date
constructor:
var date = new Date(jsonDate); //no ugly parsing needed; full timezone support
Website:
The Web Site project is compiled on the fly. You end up with a lot more DLL files, which can be a pain. It also gives problems when you have pages or controls in one directory that need to reference pages and controls in another directory since the other directory may not be compiled into the code yet. Another problem can be in publishing.
If Visual Studio isn't told to re-use the same names constantly, it will come up with new names for the DLL files generated by pages all the time. That can lead to having several close copies of DLL files containing the same class name,
which will generate plenty of errors. The Web Site project was introduced with Visual Studio 2005, but it has turned out not to be popular.
Web Application:
The Web Application Project was created as an add-in and now exists as part
of SP 1 for Visual Studio 2005. The main differences are the Web Application Project
was designed to work similarly to the Web projects that shipped with Visual Studio 2003. It will compile the application into a single DLL file at build
time. To update the project, it must be recompiled and the DLL file
published for changes to occur.
Another nice feature of the Web Application
project is it's much easier to exclude files from the project view. In the
Web Site project, each file that you exclude is renamed with an excluded
keyword in the filename. In the Web Application Project, the project just
keeps track of which files to include/exclude from the project view without
renaming them, making things much tidier.
Reference
The article ASP.NET 2.0 - Web Site vs Web Application project also gives reasons on why to use one and not the other. Here is an excerpt of it:
- You need to migrate large Visual Studio .NET 2003 applications to VS
2005? use the Web Application project.
- You want to open and edit any directory as a Web project without
creating a project file? use Web Site
project.
- You need to add pre-build and post-build steps during compilation?
use Web Application project.
- You need to build a Web application using multiple Web
projects? use the Web Application project.
- You want to generate one assembly for each page? use the Web Site project.
- You prefer dynamic compilation and working on pages without building
entire site on each page view? use Web
Site project.
- You prefer single-page code model to code-behind model? use Web Site
project.
Web Application Projects versus Web Site Projects (MSDN) explains the differences between the web site and web application projects. Also, it discusses the configuration to be made in Visual Studio.
Best Solution
EDIT: Do not use the Membership Provider as-is because it is horridly inadequate in terms of protecting user's passwords
In light of the fact that googling "membership provider hashing algorithm" turns up this answer as the first result, and the gospel that will be inferred, it behoves me to warn folks about using the Membership Provider like this and using hashes like SHA-1, MD5 etc to obfuscate passwords in databases.
tl;dr
Use a key-derivation function like bcrypt, scrypt or (if you need FIPS compliance) PBKDF2 with a work factor sufficient to necessitate the hashing time for a single password to be as close to 1000ms or more.
Hashes are easy to brute force these days with ample examples of data breaches in recent history. To prevent your user's passwords from ending up on pastebin in the next hack, ensure that passwords are hashed with a function that takes a sufficiently long time to compute!
Instead of Membership Provider, try IdentityReboot or the newer implementations from Microsoft that Troy Hunt talks about at the least.
It's also interesting that on the same google results mentioned above I find a tutorial showing folks preciously how easy it is to brute force these password hashes using popular tools like JtR or Hashcat. On a custom GPU rig, SHA1 can be cracked at a staggering rate of 48867 million hashes per second! With a free dictionary like rockyou or the like, a motivated person with your database will very quickly have most of your users passwords. As a developer, it's your ethical responsibility to do what is necessary to protect the security of your users' passwords.
The default hashing is SHA1 but they also salt it and base64 it:
If you want to know more about how to change it I still need to find out (unless using custom provider see below) however SHA-1 is pretty good for now. If you are looking to reverse it or lookup from this these guys did some work on that: http://forums.asp.net/p/1336657/2899172.aspx
This SO question will help in reversing or duplicating this technique if that is what might be needed. Reimplement ASP.NET Membership and User Password Hashing in Ruby
If you are making a custom provider you can create your hashing and encryption algorithms and methods.
http://msdn.microsoft.com/en-us/library/aa479048.aspx