I'm developing a new website (ASP.Net, VB codebehind pages, .Net 3.5) to replace a "Classic ASP" site.
Some of the pages are 'public' and the rest require authentication - in this case it's done by reading DoD-issued CAC cards through the keyboard.
Now, for 'production', they configure IIS so that it does the authentication challenge (reading the card and requesting a PIN) when it hits a certain directory (/secure in this case) so that all pages in that tree are secured.
I'm coming ot the point where I need to see some of the information fomr the card - but when I "F5" the website I'm developing, all the Request.Clientcertificate stuff is empty - there's no 'challenge' happening with the Cassini ASP.Net development server.
I see references to "configure IIS to put SSL on the target directory" - but I'm not running IIS on this development PC (nor is the other developer who's going to run into this shortly). The network support people will be doing this when the site is eventually copied into production but I need to test certain security features now.
How can I configure the server that came with VS2008 to read the CAC card and 'load up' the server/session variables that I need to query? Alternatively, is there anything I can put into the .aspx or .aspx.vb pages themselves that can simulate or trigger the security challenge?
Thanks in advance.
Short answer. Cassini doesn't support that kind of security.
I would hope you found a solution to this by now... but just in case, I will tell you that I do similar development and I ran into the same problem. The only "solution" I found was to simply publish the website/webpage to a server with IIS configured to require client certificates, etc...
Of course, this does prevent you from using the "debug" feature in Visual Studio, but there is always the method of injecting debug statements into code [e.g.: response.write() followed by response.end() if necessary]... I also built a page I used for enumerating all the strings available from request.clientcertificate(), and even later expanded it to run a provided regex for searching the entire certificate...
Hope those ideas prove useful!
Related
It may be a silly question but why one would like to attach debugger to IIS instance?
These SOs
Attach Debugger to IIS instance
How do I attach the debugger to IIS instead of ASP.NET Development Server?
show you how to do it but could you let me know what are the benefits of doing this?
One time, in my entire career, we had a web app that started getting strange errors that had us baffled. We tried a dozen things to try and figure out what was wrong, but we were panicking and needed an answer immediately. So, we attached a debugger to the production instance and set up a few watch/break points. It helped us track down the errors and fix the problem.
Naturally, it hung the server during our debugging session, and made people mad, but no more mad than they already were, because of the problem we had.
It would not have been necessary if the code had been written better, with error logging and diagnostic points. I don't expect to ever do it again.
Apart from TimG's post a couple of reasons I can think of are:
To debug the application in a closer representation of its
production environment
To debug on a remote machine
Example, like #TonE #1 -- in order to test a deployed website (with web.config transformations) locally, like if you can't remote debug a live website or just need to test config transforms (since you can't run them in-place):
Open site project from C:\Dev\AwesomeWebSite\AwesomeWebSite.sln
Publish the site to a local folder C:\Webs in Release mode (or Whatever mode)
Set up a local IIS website pointing at the published project
Do stuff on the locally-deployed version (e.g. browse pages, make webservice calls, etc)
Attach VS to w3p.exe (appropriate instance) in order to debug the deployed version
You might be able to effectively do the same thing by instead pointing the Project at your IIS website per this answer.
i have an asp.net 2.0 site which is compiled and has been put in the IIS virtual directory
however the new changes cant be seen by some users, and some other users can see the new changes on the web site, i have tried deleting cache and cleaning internet settings and trying with mozilla and chrome and still cant see the new changes.
we also tried cleaning the connection pool on iis.
is there anything more i can possibly do?
Have you confirmed that the machines are hitting the right server? Ping the URL from the "bad" machines and see what it resolves to.
The javascript changes may need browsers to download newer script which was published. (Cached javascript might be older)
For session based changes, if users retained older session, the changes may not reflect until they restart the session.
I found the answer, the server was being split in two machines, and when the server admin updated files only did in one of the servers, not both, now both are updated and running ok, thanks every one for the suggestions.
Two things to try (if Bill Gregg's suggestion doesn't work):
1) Bounce the web server services.
2) Download a freeware app called CCLEANER (formerly called Crap Cleaner....it was seriously called that). This app (when configured correctly) will clean all the junk web files off client machines.
I have inherited a web application and when trying when trying to put it on the same server on a different IP and IIS site I get a page full of stuff like this in all browsers. (not sure how the server here will output this but it is basically the same as if you were to open a binary in a text editor or bad character encoding).
���r#ə6��{��Ί��&��6�K�MЀh��"Pd�AP;�RN�K9�r��<ϛ���!��GZ�4��J�z�����R'���i�j�uZLe�V`=��&��T!e]rGVx#d��N���V���w>���pc�hw��B>��^�|L�]��3�~-��g��n��n�i�>Z� �ٲ������z_�����U�,i��2��\�+���F��FB���m��r�7�v��7�}�U�N�o�G�K�o?�w凲��و�����ߓ�x!���_?��V��v�/V��olt˭Z����� >M�kwkh&��j�C3�|̓��=�8��jJ����Uo�~��T7�\w�eW�������u*���f0c��}�.����]o������7���|�;}�&O���N�)[ys��+Q��o�T�~����F����c���έm��.�Q�ů�2#P���i�ˠ�~g��u�<| $ۭ>zZ/e��'�;R�'���v�ˠ�����
I've copied the same build and all its files to the site running under another IP, used the <globalization> web.config tag and set all encoding to UTF-8 and for the hell of it I even tried setting it to ASCII.
The application, although written for users in only US cities does make use of localization resource files for Russian and Romanian since it had been outsourced to developers there. I guess they did so to make things easier on developers who may have been less fluent in english, who knows.
Besides using the exact same copy running in production and changing web.config encoding settings I have found it runs fine on my IIS 7/Windows 7 workstation, tried throwing a uncompiled copy up there with .cs files and all, wrote a simple ASPX page that performed a response.write (which came out fine).
So as you can see I am pretty much at a roadblock and decided to ask the fine professional community we have here. Any input you may have on this matter would be highly appreciated.
I fixed it by exporting the IIS settings for the production system that it worked fine on and created a new IIS site from that file. Sadly I could see no difference between the 2 before I did this but if you run into this issue then here is another thing you can add to your list of troubleshooting tasks.
It's probably a long shot based on your description, but from a little Internet digging, a couple of forum posters have mentioned bad NICs corrupting packets. You did say you had the app on a different IP on the server -- does your server have more than 1 NIC?
Are there any particular settings one should optimally enable/disable/tweak when doing ASP.Net MVC development on local test machine Windows 7 using IIS 7.5 and moving in and out the debugger & recompiling refrequnetly (integration/troubleshooting stage now before TDD fantactics throw stones - although admittedly I could have more under test), I work with 64 bit edition but figure this probably applicable at both x86/x64?
I'll start with one:
Ping Period (seconds) - increase from 90 to 3000 (or something somewhat higher) so you can if unfortunately need to a good bit of time whilst debugging or disable ping on local test machine.
Credit: http://blogs.msdn.com/johan/archive/2007/09/12/my-web-application-times-out-when-debugging-in-iis7.aspx
However I see over stuff such as:
Disable Overlapped Recycle & Recycling settings etc.. that I wonder if could increase performance or make debugging less friction
Question prompted by the annoyance that I've ran across a few recent debugging issues (not apparent in production) including a random, and tempormental error "An assembly with the same simple name blah-blah-lah-assembly-definiton has already been imported . Try removing one of the references or sign them to enable side-by-side." (iisreset resovles) and generally slow debugging attaching. The points and answers to this question need not help with the above (I believe it may be related to spark view engine as that where the stacktrace ends) but figure it worth mentioning incase someone has a direct suggestion *
quick tip: if you're experiencing slow response times (~1-1.5 sec) from browsers other than internet explorer (eg: firefox, chrome, safari) while running your mvc/ other web app on your local machine using win7/vista, it is due to dns resolution with ipv6.
firefox solution: disable ipv6 in about:config (boolean cfg 'network.dns.disableIPv6')
machine wide soft solution: uncomment the good old localhost address in the hosts file (%WINDIR%\System32\drivers\etc\hosts):
# localhost name resolution is handled within DNS itself.
127.0.0.1 localhost
# ::1 localhost
machine wide hard solution: disable ipv6 completely
credit goes to this blogpost: http://weblogs.asp.net/dwahlin/archive/2007/06/17/fixing-firefox-slowness-with-localhost-on-vista.aspx
Embarcadero guys just published a fresh article on similar topic for Delphi Prism (aka Delphi for .NET), so why not take a look on their suggestions?
http://edn.embarcadero.com/article/40108
From the experience i have working with asp.net mvc, i can tell that there are no special settings for IIS 7 or IIS 7.5 for working on asp.net mvc projects. It works fine in the default form, you just need to create a new website and point it to the folder that has the files for you application.
For debugger if you ask, you can simply put a breakpoint in the code and hit that breakpoint when you run the application from visual studio. But by default the application will use the development web server that fires up when you run a web application from visual studio. If you want to the application to run using the IIS installed on your system you will have to change the project settings. See here for a screen shot of how to do so
http://blogs.bootcampedu.com/blog/post/Debugging-aspnet-mvc-application-using-IIS.aspx
Additionally you can also use System.Diagnostics.Debugger.Break(); for putting a break point in the code.
If you only want to debug your application, I recommend to use the built-in development server of Visual Studio.
If you debugged the most of it or want to do that on IIS, I recommend you the Ctrl+Alt+P shortcut, which enables you to attach a debugger. Select w3wp.exe and you can debug with IIS.
Basically, what I'm wondering is if I need to set debug="false" before hitting the "Publish Web Site" button or if I can switch it after all the files have been published.
You do not have to turn that setting off, however, you will want to set debug="false" before running the website as a production application. It will have a profound impact on your site's performance.
As to what Ryan wrote - see debug code in production.
Another option you may want to use is retail="true".
You can keep it set to true when you publish/precompile, but once its at a production status, its strongly recommended that you set the value to false, the reasons are here outlined by Scott Guthrie (he manages the ASP.NET team) himself.
Highlights from Scott's post:
Doing so causes a number of non-optimal things to happen including:
1) The compilation of ASP.NET pages takes longer (since some batch optimizations are disabled)
2) Code can execute slower (since some additional debug paths are enabled)
3) Much more memory is used within the application at runtime
4) Scripts and images downloaded from the WebResources.axd handler are not cached
On the production server you could put deployment retail=”true” in machine.config. This will ensure that debug is always false for that server. Details here.
Unfortunately, no. You can publish it with the option set to true, although you certainly should not (if the page is going into production). I publish apps to a test environment initially with it set to 'true', the set it to false in the test environment, and absolutely to false when into production.
But your site will build and publish fine to whatever environment you send it to with the debug set to true. As I understand it, there are a quite a few sites out there that in production with this set that way. Dror posted a great link to the issues that come with leaving this option on.
I hope this adds some value. I have been learning a lot about msbuild, and what a incredible tool it is!
If you are publishing sites to production, there is probably some of the steps that you would like to automate. If you want to use a batch file to do your publish instead of the visual studio interface, or included this in your build scripts, after you have compiled sucessfully the following will publish your website.
msbuild <yourProjectFile>.csproj
/target:"ResolveReferences;_CopyWebApplication"
/properties:"debug=false;
retail=true;
WebProjectOutputDir = <YourCorrectOutputDir>;
OutDir = <YourCorrectOutputDir>\bin\"
The time we have spent in our time, investing in fairly extensive build scripts, that even run a few basic http get reguests against the site after we are done building and publishing it, has reduced a huge amount of frustrations.
I am a firm beleiver of automating as much as possible, machines dont seem to forget to do things as often as I do :D
Hope it helps
Cheers
Rihan