I would like to develop a custom application (multiple screens, complex processes) on top of Sharepoint Foundation 2010. I decided to write visual web parts for simple logic and Silverlight web parts for complex application logic. First of all: Is this decision ok?
My application will use it's own data in a separate DB. The only connection between my DB and Sharepoint will be users. Users will authenticate against Sharepoint and access my application from there. They will belong to certain roles which will define their rights within my application (either admins - hierarhicaly managing data of subtree users - or they will be regular users - only able to see their own data).
Within my application (and DB) all these users will be hierarchically related. Users with subtree of users are admins of their subtree.
Problem?
If I do write web parts (of whatever kind), how do I ensure that these same web parts are not used in other Sharepoint sites as well? It would most probably break the application and it could of course make it possible to replicate the same application but using different users...
I thought I could as well write application pages (so my application would be in _layouts folder as I understand it), which would make it possible to not reuse my application, but users and rights are assigned on site level so I'm not able to define security in Sharepoint directly... So I can't win this way either...
These are all specualtions on my thin Sharepoint development experience, so correct me of I'm wrong in any of the above... But beside all that what would you suggest? How would suggest I should do this?
To get straight to the point WebPart are for reuse and personalization when you develop a web part.
To Answer your first question : Is WebPart development okay, Partially yes because, you have multiple option to prevent a web Part being accessed or used in other SharePoint Web Application or website.
First way is to deploy your webpart to the Applications Bin Directory so that your code is accessible only to your application not others.
Second way is that WebPart can be used in a SharePoint web application only if there is a Safe Control entry in the Web.Config.
Third Way is to prevent the users from Personalizing any page in SharePoint so that they cannot deploy any Web Parts even in their own Personalized Pages. (this can be achieved by removing personalization rights).
Farm Admin should be a Good guy that he will not add that safe control entry in other websites that doesn't want this webpart functionality.
Application Pages are not good idea because by the name you could guess they are shared across the farm & is accessible to all the SharePoint websites deployed in the server.
In cases if you are not okay with the above to Web Part approach , I would suggest to create sub sites as per the permission requirement you want and provision pages that will go in to each of the sub sites. Each of these pages will have a ASP.NET User control that hold the Business Logic you have written.
Related
I have an ASP.NET Core web app running on IIS. It's using ASP.NET Identity standard user/pass authentication and IdP initiated SSO for certain clients.
Now I need to get some of the web app features to MS Teams. I have gone through the MS Teams dev portal and have a test application up and running. The sample app itself is a Blazor app that we need to install as a separate application (let's say on an Azure app service or IIS).
Is it possible to have the Teams & my existing web application in the same project so that I don't have to create a separate site?
The reason is web app is multi-tenant enabled and have a API layer which anyway will have to be used by Teams app. So, if I can put these two together it may be easy? So in my solution, teams will have separate set of views/controls etc..
I am not sure whether my thought process is wrong in this case. Questions here and here doesn't seem to answer my requirement.
Anyway is this possible?
yes it is possible you can run multiple projects in MS teams the difference would be that they will be having different api endpoints and will be called by different names vice versa. I cant get to know what you exactly want to know but I hope it will help you.
I don't have any code yet as I don't know where to start! I see on the web that I'd need to select
on the Access toolbar external data >> more >> data services. Then it asks to point to a xml config file. Which I don't have and would need to create. I have the connection string from a VB.net application.
sWIPConnString As String = "SERVER=(DESCRIPTION=(ADDRESS=(PROTOCOL=TCP)(HOST=fake3465-vip.ent.agt.bb.ca)(PORT=41521))(CONNECT_DATA=(SERVICE_NAME=fictitious_service_name)));uid=APP_getinfo;pwd=thispassword;"
I'd have to convert that to an xml version. Any help would be appreciated!
Thank in advance
Pete
But those data services are not just any old plane jane web site. They are web sites that have installed, setup, and the developers of those web sites setup that data service connection. And these custom connections are NOT general web sites, and they are not general web services that many sites have. And they are not a web API written around say SOAP or some REST standard.
So unless that web site decided to adopt this Microsoft specific means and method to expose data, then you not be able to use this feature to simple connect to any old web site out of the blue. If you have a existing web site that exposes some web services? Then you have to use MSXML and consume that web data yourself. That option in Access is not some general purpose setting or feature that allows connection to any old web site - only ones that have created that web service written to the business connection options that Microsoft created.
It not clear if you planning to create some web services on the target web site (that would assume you're the developer of that web site), or you trying to consume existing web services that the given site exposes. Even in this 2nd case, those exposed web services or even REST calls has ZERO to do with the feature in Access.
so that feature is of only use for connecting to web sites that offer specific created connection based on that standard from Microsoft - it not a general web service consuming feature built into access and you can't use that feature as such.
How to make a web service call from Access? Well, it has ZERO to do with that feature. Here is a MSXML exmaple:
How to use XML web services in Access2007 which are built on Visual studio (2008/2010)
I am building a service-oriented system for personal use (plus few friends may have limited access as well) - the aim is to have a dashboard for controlling my apps running on various machines such as Raspberry Pis (and potentially to be expanded to a VPS or few in future).
The architecture itself is pretty simple. For authentication I want to use AWS Cognito. Services would communicate with WebAPI (and potentially with eachother) using gRPC within a VPN, and dashboard would be served by Blazor server-side (may move to Blazor WASM Hosted model if I find a need for it). Each of the processes may or may not be on the same machine as any other (depending on the purpose). Blazor server may or may not run within VPN (I might want to move it to a separate web hosting later).
I created a simple diagram to visualize it:
The problem comes with authentication. I want to have Blazor server-side and API as a separate processes (for now they're going to run on the same machine, but I may want to move it elsewhere eventually). Ideally authentication should be handled by API, so authentication is client-agnostic, and the API can use it to verify if the logged in user can perform an action - which by itself is simple.
However, I want Blazor server to use and validate that token as well in order to determine what to display to the user. I want to do with the least amount of calls possible - ideally avoiding querying API for every 'should I display it or not?' choice.
I could easily do it by sacrificing possibility to move API elsewhere, and just merge Blazor Server and API Gateway into one project. For my current purpose it would be enough, but it's not an ideal solution, so first I want to look into how could I achieve my original vision.
How could I achieve this (with minimal amount of Blazor server to API queries)?
I was googling for solution a lot, but so far only found either examples of using Blazor server and API as one project, or using client-side calls to API directly.
Thank you good folks in advance.
Custom Web sites built on SharePoint are cropping up everywhere (just visit topsharepoint.com to see). With that said, my question pertains to creating a fully customized, branded site using SharePoint as the CMS as depicted by many of the topsharepoint.com sites.
I understand the concept of creating the custom master master page(s) (SharePoint 2010 even includes a minimal.master to start). The problems I have are:
What site template does one use? In 2007 the recommended front-facing Web site site collection template was the Publishing Portal. Is this still the case?
What navigation do you use? Do you leverage the OOB navigation? If so, how do you style it extensively?
How do you keep the on-page editing capabilities within the new site template?
Are there any online tutorials are walk-throughs that address all of these issues? I have been searching, but it's really sparse out there.
I want to make use of some of the ASP.NET 3.5 capability within SharePoint 2007. In particular, I want to do the following:
Provide REST and maybe JSON through HTTP so that another product can consume SharePoint content.
Provide AJAX web parts within SharePoint. These will probably have little to no server side controls. Most content will be loaded using Javascript and hitting an external system (primarily not SharePoint) over HTTP that provides REST or JSON.
Provide this capability as a product. This is not a one-off solution for a single implementation.
My main concern is push-back from IT groups not wanting to change their SharePoint environment to allow for the product to work. So, I'd prefer to be able to say that what I'm doing is "supported by Microsoft", but I'm not sure that will be the case.
I realize that I could create a separate (non-SharePoint) web site on the SharePoint server(s) for WCF endpoints that provide SharePoint data to an external application. I would rather not do this because that won't help my web parts (if they need help) and that makes deployment harder. Proper SharePoint deployment will automatically have SharePoint update all necessary files (e.g., web.config) on any new web front end added to the farm and this wouldn't follow that pattern. In addition, I'd lose the ability to use SPContext.Current.
I have read much of Daniel Larson's book on Developing Service-Oriented AJAX Applications on the Microsoft Platform (good read, BTW), esp. Chapter 11 on extending SharePoint. He outlines WCF, ASMX, and HTTP Handler options and for the most part recommends the HTTP Handler option. It appears that the HTTP Handler option has minimal changes to web.config.
I have also seen a blogs on SharePoint as a WCF Host, SharePoint 2007 and the Thin .NET 3.5 Development Model, How to: Get up and running with .NET 3.5 in your SharePoint environment, and Enabling .NET 3.5 in SharePoint 2007 Sites, the Lazy Way. As well as the "Silverlight (.NET 3.5) Config Feature" (and maybe even the "Ajax.Config Feature") in the SharePoint 2007 Features CodePlex Project. It seems that all of these options do some fairly drastic changes to the web.config and may not be acceptable to potential customers.
What are the opinions out there on this? What about if I want to use the AJAX Control Toolkit (I've used this before in SharePoint, but it has been a while)?
Note that we probably could require SharePoint SP2 if that helps, but I don't think it does.
Note also that Silverlight is not a requirement for the SharePoint web parts, but allowing for it might be nice.
Your first point could be solved by a custom wrapper to the SharePoint web services, presenting the API that you want to present, rather than the generic web service.
Your second point, AJAX enabled pages and web parts, is already possible - how to enable AJAX in SharePoint.
.NET 3.5 Is supported in SharePoint (as of SP1 I believe), However you will not be able to get away from making web.config changes and installing .NET 3.5 on the servers - it will likely only be there if there are already AJAX web parts in use.
Aside from that what you are looking at is largely independent of SharePoint - If you can build something as an aspx page or asmx web service you should be able to deploy it to a SharePoint site.
If you want to avoid 3.5 installation issues altogether you should be able to build something totally separate - jQuery for the web parts (no server side components needed) and for getting data out of sharepoint build something that translates calls to the standard web services into a friendlier interface.