Microsoft's AntiXSS library has been broken for 6 months and it looks abandoned (that may or may not officially be the case). Due to a security issue with previous versions, it is not safe to rollback to an earlier release. Are there any good actively developed alternatives for AntiXSS and web security in general when working with the Microsoft (specifically MVC) stack?
There's a new xss sanitizer shipping with the June 2012 release of the ajax control toolkit. The toolkit was originally using the microsoft anti xss library as well, so they experienced the same problems. The new sanitizer is based off the HtmlAgilityPack
See http://stephenwalther.com/archive/2012/06/25/announcing-the-june-2012-release-of-the-ajax-control-toolkit.aspx
I have the same issue and I've been looking high and low for a solution but haven't found anything else out there.
Basically, I think the only option moving forward is to use some flavour of WMD (like they do here on Stackoverflow)... send it back to the server as WMD markup then save it in the database as HTML and then convert it html when spitting it out on the page on the server.
This could be a good start: http://code.google.com/p/pagedown/
There is a unofficial port of WPL called AntiXSS.NetStandard that support AntiXSS in .NET Standard 2.0 (.NET Core 2.0+, .NET Framework 4.6.1).
Related
We are developing a cross platform mobile application using Xamarin. I have noticed there are different ways of structuring your code using Shared code or PCL/.net standard.
I attempted to use .net standard and what i have found is that it doesn't include all the libraries such as using ado stuff , datatable/datasets using system.data. Or using system.net for example. Other functions have less overloads and seems that its a stripped version of .net to work across platforms. Is there any way to add this functionality or use a broader range of .net?
You are correct - .Net Standard and .Net Core are stripped down versions of the full .Net framework. They contain only features that can be used on all platforms (Mac, Android, iOS, Linux, Windows, etc.)
The full .Net framework only needs to work on Windows, so there are additional things that you can do based on the fact that there is less complexity in implementing and that the code base is more mature (cross platform is still pretty new by C# standards). To the best of my memory, System.Net should work if you have your references correct, but System.Data will not (or at least direct database access is not possible)
You can regain some functionality through NuGet packages, but it won't be the same as using WinForms or something like that...
My best advice would be to program against an API. You can use a web server that runs on the normal (full) .Net framework, and does all the heavy lifting using all the .Net features that you are accustomed to. Your Xamarin app would send and receive data from the API and basically provide a mobile front end for whatever you are doing. This approach makes sense for most apps anyway, and is generally what you would be doing anyway if you used Swift and Java to create separate iOS and Android apps.
I'm working with the code from google drive in visual studio 2012 (C#). I managed with hours of fiddling around with nuget reference the necessary libraries.
I compiled the test application and got the following warnings:
'Google.Apis.Authentication.OAuth2.DotNetOpenAuth.NativeApplicationClient' is obsolete: 'NativeApplicationClient is not supported any more and it's going to be removed in 1.7.0-beta. Consider using the new Google.Apis.Auth NuGet package which supports .NET 4, .NET for WindowsStore apps, Windows Phone 7.5 and 8 and Portable Class Libraries as well'
'Google.Apis.Authentication.OAuth2.GoogleAuthenticationServer' is obsolete: 'GoogleAuthenticationServer is not supported any more and it's going to be removed in 1.7.0-beta. Consider using the new Google.Apis.Auth NuGet package which supports .NET 4, .NET for Windows Store apps, Windows Phone 7.5 and 8 and Portable Class Libraries as well'
'Google.Apis.Drive.v2.DriveService.Scopes' is obsolete: 'Use DriveService.Scope instead. This enum is going to be removed in version 1.7.0-beta.'
I did not modify the code other than adding in the client_ID and client_secret. Other than that, it appears to run...
I'll also mention that I am using the nuget Google.Apis.Auth package.
The code behind the DriveService.Scopes warning is using DriveService.Scopes not Google.Apis.DriveService.Scopes (look at the code on the link; mine is the same).
With the google admin api being deprecated and google breaking the old api almost every other week it seems, I'm anxious to get on the new API. However, with what I'm seeing here I'm wondering if that's a good idea or not. I could be trading the frying pan for the fire. With that said, what are we supposed to be using if your current example is already obsolete?
First of all you should use the latest version of the library, that's the version that we maintain, provide fixes, new features and so on. You can get it using NuGet.
The sample code in the page you mentioned wasn't updated lately. Take a look in our samples repository (and specifically in the Drive API sample).
Google.Apis.Auth is the right package to use. The reason the old package (Google.Apis.Authentication) is obsolete is based on the fact the we wanted to support different Windows platforms like WP, Windows 8 applications, ASP.NET MVC. We also simplified the OAuth2 "dance" which was so complicated before.
Last thing - If we make any incompatible changes in the library we document them in our announcement blog, so our users will be able to make the right adjustments . I recommend you subscribing to this blog to get updates about our library.
Hope everything is clear now :)
Our VB6 application uses a 3rd party control (PowerTCP from Dart) for SSL3 connectivity. However, this doesn't seem to work on Windows 7 - and I have not found any useful information on what I can do to make it work.
Is there a VB6.0 compatible control that will work on Win 7 for SSL3 communication?
Unfortunately, I can only suggest a workaround, not a solution: If you do not find a suitable ActiveX control for your VB6 application, you might consider migrating the communication part of your application to VB.NET.
This has the following advantages:
Calling .net code from VB6 is not hard.
The .net Framework has a built-in SSLStream class, which might already do what you want, so you're not dependent on a third-party component.
Since VB6 IDE support ended in April 2008, you will probably want to migrate your application to VB.NET sooner or later anyway. Therefore, migrating parts of your application now might be a better investment of your time than familiarizing yourself with a new third-party ActiveX control.
It has the following disadvantages:
One more layer in your application: Your VB6 code can call the .net code, but not vice-versa.
You need to familiarize yourself with the .net-COM interop stuff (it's not difficult, but it's something that needs to be done).
Your deployment process becomes more complicated, since you require the .net Framework to be installed on your customer's machines and you need to register your .net library as a COM component (so that your VB6 application can access it).
Dart still support the ActiveX control - why not ask them for help directly and post a question on their support forum?
Apologies in advance if you've already tried this.
I need a WYSIWYM markdown editor for my web application and I heard WMD was the obvious choice.
To my surprise WMD breaks in IE8. What other option do I have, or is there a version that's been tested on IE8 and is compatible?
Check out wmd-new. According to its website:
This version of WMD has been tested with IE 6, 7 and 8 RC1, Firefox 3, Safari 3.2, Chrome 1.0 and Opera 9.6. iPhone and iPod Touch support is rumored to work with the exception of the link/image prompt location. There are a few (minor) known issues with keyboard handling in IE and Opera. See the issues page for more details.
[...]
NOTE
Version 2.0 of this code was developed as a private bugfix/feature branch for Stackoverflow.com and is missing most of the optional features found in the original WMD as SO did not use them. Now that I'm putting this out on Google Code I'll be adding the new features back in v2.1 due out sometime in February 2009. Version 3.0 should be released in February/March 2009 and will a major rewrite making use of jQuery.
EDIT: I didn't notice it immediately but this project hasn't release any source code.
EDIT2: As pointed out by warren in a comment, a "Stack Overflow branch of WMD" is hosted on github. See Reverse Engineering the WMD Editor for more details.
I haven't used WYMeditor myself, but their supported browsers are:
Gecko-based browsers (Firefox 2.0+, SeaMonkey, Galeon, Epiphany, ...)
Microsoft Internet Explorer 6, 7 and 8
Opera 9.5+
Safari 3.1+
Google Chrome
The version of WMD on derobins' github should work fine with IE8.
There is one listed on the wikipedia page - but I've not used it: WYMeditor
I sugest Tinymce a wonderful Javascript WYSIWYG Editor, with loads of functionalities, and its opensource, it as versions for PHP, ASP, JSP and CouldFusion, multi language, and some others functions, very simple to customize with only the specific functions you want him to enable for your users.
Check out Tinymce website:
http://tinymce.moxiecode.com
Regards
EDIT:
I been using it for the past two years never had any problems with it.
I wanted to know what i shouldn't do in code that will prevent my C# app from running on mac.
In general you shouldn't use anything from the Microsoft.* namespaces, no PInvoke (DllImport in C#) and UI might be problematic as well.
Further information on Mono compatibility is contained in the Mono Guide Porting Winforms Applications. Existing applications can be checked for compatibility using the Migration Analyzer tool.
UPDATE: PInvoke actually works in Mono, but if you want to have it working cross-platform you must provide a native shared library with the same interface for each platform (i.e. Win API most likely will not work).
Mono's Application Portability guide is a good reference.
In addition to divo's recommendations, I would recommend the Mono Migration Analyzer (MoMA) tool: "The Mono Migration Analyzer (MoMA) tool helps you identify issues you may have when porting your .Net application to Mono"
Also, I would keep an eye on Miguel de Icaza's blog, and the Mono Project website.
In his presentation for the Boston.NET Users Group this month, he showed a preview of a Visual Studio plugin that launches your app on Mono using a VM! This lets you test compatibility during the development process.
I believe their goal was to release it at TechEd 2009, so look for an update over the next month or so.
You will, at the very least, want to try and avoid using Windows Forms, since that is just a paper-thin layer on top of the Windows native UI.
Mono emulates it somewhat with help from WINE, but I wouldn't trust that.
Mono did this a while ago but the effort was abandoned. See WinForms on Mono for more information. Thanks jpobst.
Try using GTK# or Qt# (although I'm not too sure the latter one actually exists) for cross platform support. You might also consider using Java with SWT or even Swing instead of C#, but that will probably not be an option you're willing to consider.
Using anything related to P/Invoke is probably also a bad idea, since that invokes native code which will probably not be portable (unless you write it yourself, then you can choose to make it portable).
I'm not sure if it is possible with mono, but WIN32 API calls will definitly not work ;)