I've been using VS Code for a year or so now. I have no idea how VS Code Extension security is handled.
I'm alarmed by things like this:
Markdown Preview Enhanced (927K+ downloads)
Markdown Preview Enhanced (fork that points to the original repo) (2k+ downloads)
Some questions I have are:
What does Microsoft do to ensure Extensions we install are safe?
Are they scanning the Extensions for known vulns?
Is VS Code safe to use in an Enterprise Environment?
How can I tell?
Why are duplicate extension names allowed!
There are security and marketing implications by Microsoft allowing "package-squatting".
Does anyone have insights to share regarding VS Code Extension Security?
Hm. Unfortunately, the link to "extension marketplace terms" that #jonrsharpe provided does not include the word "extension". If you extrapolate VS Code Extensions to be covered by the Azure Marketplace terms (as alluded to in the text), then you get this little tidbit:
https://azure.microsoft.com/en-us/support/legal/marketplace-terms/
Publisher Privacy Policies. Publishers are responsible for providing
privacy statements that describe their privacy practices with respect
to Customer Data collected by their Offerings or any customer
information that they receive from Microsoft. Unless indicated
otherwise in connection with a Marketplace Offering published by
Microsoft, Microsoft’s privacy, security, and data location and data
retention policies will not apply to any Marketplace Offering or to
Publishers’ use of any Customer Data or other customer information.
In short "...Microsoft's privacy, security...policies will not apply to any..." VS Code Extensions OR to "...Publishers' use of any Customer Data or other customer information."
Microsoft does NOT handle VS Code Extension Security.
Related
We have a custom solution made up of several screens that are packaged as a customization package. We'd like to be able to lock that down so that users need to purchase a license key to use these screens. I don't want to re-invent the wheel, so I'm wondering if there are standard examples (if this has been done before) on how to integrate this with Acumatica's license system.
It is not possible to integrate with the Acumatica licensing system. We implemented our own licensing and required the license when the Acumatica license has been applied. This is indicated by PXLicenseHelper.License.Licensed
I should point out I did spend a good amount of time on this very question before we implemented licensing for our product.
Previously when provisioning list, libraries, site columns, content types, list definitions etc in SharePoint I typically used SharePoint features, deployed via a WSP - or used PowerShell scripts. This meant I had a package that could be deployed to DEV / TEST / PROD.
I'm working with SharePoint within Office 365 and unsure on the best way to provision lists / libraries / features within SharePoint.
Options:
No Code Sandboxed Solutions
Trying to avoid using these as the information from Microsoft on whether they are deprecated is flaky - however sandboxed solutions would allow me to deploy features with list definitions etc. I know sandboxed solutions with c# are definitely deprecated, but the info around no code solutions is poor.
Apps
I know apps can provision at both the app and host web level, but creating lists, libraries etc using the CSOM seems like a lot of effort and a step backwards.
PowerShell
The SP Online PowerShell is nowhere near as powerful as on-prem SP. I can provision site collections through this, but not lists or libraries...
I'm keen to know how other developers are deploying to Office 365, specifically around provisioning sites with specific list definitions, libraries, content types and so on...
Thanks
Microsoft did clarify the position on No Code Sandbox solutions - http://blogs.msdn.com/b/sharepointdev/archive/2014/01/14/deprecation-of-custom-code-in-sandboxed-solutions.aspx
Also if you are looking at using Powershell to deploy then you might want to go down the route of using CSOM from within PowerShell - SharePoint Client Browser for SharePoint 2013 is good for setting up a session also very good for viewing the content of a 365 tenant - http://spcb.codeplex.com/
I have been using code based provision for almost two years without any issues at all.
Server side model works just fine, CSOM has some limitation but stil cool one and JSOM could deliver the same feature set as both CSOM and SSOM, sorta 95% :)
PowerShell is not the best option as it hard to integrate into CI, put some unit testing and regressions.
As you mentioned, this is "step back", but if only you don't have any framework or foundation for that. My libraries are internal one, but there is SPGenesis at codeplex and SPMeta2.
As community don't really care, need or with such libraries for provisioning (yep, let's face it), there are much such libraries at all, but there are lots of "MVP" samples sorta "hello world" level.
Finally, what I would suggest is to invest your time and effort in code based provision.
This is a future, that's it ;)
UPD
Struggling with SharePoint's API inconsistency, bugs, "by-design" behaviour, unaffordable amount of time to write, support and upgrade WSP packages and XML, a team of passionate SharePoint professionals decided to come up with robust, testable and repeatable way to deploy such artifacts like fields, content types, libraries, pages and many more.
Enjoy and let us know how it goes.
SPMeta2 at GitHub
SPMeta2 at Nuget
SPMeta2 Documentation Wiki
SPMeta2 Bugtracker
Am working for a Medical devices company and we are trying to use Static code analysis tools for our development.Can somebody help us in validating whether Visual Studio 2012 Code Analysis feature is complaint to FDA or not?
I believe TFS can be validated for FDA Compliance for Static Code Analysis and other requirements depending on your QSIA Intended Use. As mentioned in OP's comment the key is validating how you are using a tool, not whether it is validated "out of the box". I believe you must validate that you have configured and use static code analysis in a way that is compliant. Just having a tool doesn't make its output automatically compliant (unless there is a "FDA-compliant" setting that cannot be disabled :-)).
Food and Drug Administration (FDA) Compliance with Visual Studio 2010 (MSDN whitepaper by Northwest Cadence, June 2011)
has an extensive walkthrough of TFS features mapped to FDA compliance and FDA document "General Principles of Software Validation". Static code analysis is specifically mentioned. Here is the relevant excerpt:
Static Code Analysis
The static code analysis in Visual Studio 2010 has several hundred rules that check code for potential code errors in several areas, which include design, naming, reliability and security. These rules can be combined into rule sets that allow only a specific subset of the rules to be run, highlighting potential problems. These range from the “Minimum Recommended Rules," which focus on the most critical problems in your code, including potential security holes, application crashes, and other important logic and design errors, to the “All Rules” set. which contains every available rule. It’s very easy to configure a custom rule set to focus your code analysis specifically toward your needs.
There may be other references that are (or will be) relevant. Try following search keywords: TFS FDA (or better yet use +TFS +FDA to force major search engines to have both terms). +VS +FDA might return other relevant results especially if you are looking specifically for code analysis rather than overall compliance for eSignature and other Part 11 requirements.
Please vote if you found this helpful. Thanks! -Zephan
VS2012 is not compliant to FDA
Let's assume that you've created a SharePoint solution - a WebPart, a feature for a List Template, whatever - that you are planning to sell as a product.
How would you go about handling licensing of your solution?
I'm looking for some input in at least the following areas:
Code-wise:
1.1. Where do you keep the license itself? as a file somewhere? (then what happens in farms?) as a property in the property bag of the farm?
1.2. Do you implement "home-calling" - where your solution validate the license every now and then against your company's servers?
1.3. Any other best practice in this area will be welcome...
Business wise: How do you license - per user? per server? per instance (in case of WebParts or List Templates)?
Thanks.
I could tell you what we do:
We have a separate farm solution that handles trial/registration support for all our products
The license is eventually stored in the farm property bag (you have to support multiple servers)
We have a page to enter license key under the central admin solution's page
We license by front-end, you can know the number of front-end in the farm in code.
All products have a product name and the license key is a one-way encryption containing the product name. the trial support solution handles key validation.
1.1 You have to put in in the documentation and in the distribution files.
1.2 I would not do that for a sharepoint web part.
1.3 Invest in layout, documentation, support... Not just in the product itself.
Nobody will be able to answer that without knowing detailed information about your product, your market, your competitors, the alternatives, etc. Consider this book if you are serious about pricing.
I work for a large organization and we have been utilizing SharePoint for document library. Yesterday my boss called me to his office and asked me:
"I heard that SharePoint is an ECM! So what can it do for us?".
"What kind of problem do you want us to solve utilizing SharePoint?", I replied.
"I want to know what it means when they say it is a ECM and how it can help us?", He said.
I told him it has Document Management, WorkFlow, Records Management, Search and some other stuff.
Anywho, He wants me to put togetter a list of things that SharePoint offers as an ECM.
You might find some useful info on the MS ECM team's blog.
Microsoft Office Sharepoint Server has a substantial content management system available. What was previously Microsoft Content Management Server was discontinued and that functionality was put under the Sharepoint umbrella. Usually this is referring to web content, but it can honestly be any kind of content relevant to an enterprise. It is intended to be a direct competitor to all the major WCMS out there, focused especially on the enterprise (governance, auditing, security model, etc).
That having been said, the current iteration of MOSS's EWCM pretty much blows. If you can develop your CM strategy to be parallel to MOSS, it can work out OK, otherwise it's much more pain than it's worth. Use SP for document management and use something else for content management.
Sharepoint is a collaboration platform restricted to a windows environment
Give Alfresco communities (labs) a go is my opinion here as it 'acts' as a Sharepoint server so Microsoft Office suite will not notice the difference but your wallet will...
Er... think the boss got a bit too much $$$ to spend. But really, an't we supposed to deploy a technical solution to solve a business problem.
The list of features can be found at
http://sharepoint.microsoft.com/product/capabilities/Pages/default.aspx