إلى أي مدى يمكنني الذهاب مع تطبيقات SharePoint 2013؟

Question

أنا جديد حقا في SharePoint 2013 وعملت فقط لفترة وجيزة من الوقت في SharePoint 2007 منذ حوالي 5 سنوات (لذلك أنا لا أتذكر الكثير).

يجب أن أخطط الآن لاسكارات خارجية، وربما ستستند إلى SharePoint 2013.

لقد قرأت بالفعل الكثير من المعلومات حول طراز التطبيقات السحابية الجديدة ولكن لا أستطيع معرفة المسافة التي يمكنني الذهاب إليها مع التطبيقات.

أنا أفهم أن التطبيقات لا يمكن الوصول إلى نموذج كائن جانب الخادم.ولكن ماذا يعني هذا بشروط pratical؟

على سبيل المثال، سيكون لدينا Extranet لدينا أقسام مخصصة في القائمة تم الوصول إليها وعرضها أنواع مختلفة من المستخدمين.وهناك مستخدم للطاقة يحدد الأشخاص الذين يحبون مؤسسته عرض أقسام.

هذا معقد إلى حد ما كما ترون.هل يمكنني تقديم تطبيق لهذه الحالة؟أو أنا الوصول إلى قوائم المستخدمين التي لا يمكن الوصول إليها وهذا يجب أن يكون حل مزرعة؟

Answer 1

how long is a pice of string? ;)

only joking, its a vauge question so im going to try to answer without being so vauge!

Your talking about user/group policy:

•User-only policy—This user-only policy is the authorization policy that was always applied in SharePoint 2010. When the user-only policy is used, the authorization checks take into account only the user identity. An example of when this policy is enforced is when the user is accessing resources directly without using the app.

•User + app policy—When the user + app policy is used, the authorization checks take into account both the user identity and the app identity. In particular, when this policy is used, authorization checks succeed only if both the current user and the app have sufficient permissions to perform the action in question.

An example of when this policy is used is when a SharePoint site has an embedded IFRAME that links to a Office Store app, and the app calls back to SharePoint to access SharePoint resources on behalf of the user. That is, when a Office Store app, which does not run in SharePoint Server, wants to act on behalf of the user to get access to the user's resources.

•App-only policy—When the app-only policy is used, the content database authorization checks take into account only the app identity. In particular, when this policy is used, an authorization check succeeds only if the current app has sufficient permissions to perform the action in question, regardless of the permissions of the current user (if any).

An example of when this policy is enforced is when the app is not acting on behalf of the user. An example of an app that might use this app-only policy is an expense submission app.

In the app-only policy app type, the person who installs the app (for example, a human resources manager) has the rights that the app needs, even though users who actually use the app might not have those rights.

For example, the person who installs the app allows the app to approve an expense submission that is equal to or less than $50, even though the users who submit the expense have no rights or authority to approve it. And, if the expense is more than $50, the app routes it to the appropriate manager for approval.

http://msdn.microsoft.com/en-us/library/fp179892.aspx

and also app permissions is i think what your also refering too:

SharePoint 2013 apps provide a wide variety of powerful tools and enhanced functionality that can increase the usefulness of your SharePoint 2013 deployment. When you decide to support the implementation of SharePoint 2013 apps within your deployment, you need to determine who will be installing the apps and who will be using them. You also need to determine the appropriate scope and permission levels for each app, based on how the app is intended to be used.

App permission request scopes

SharePoint 2013 apps use app permission request scopes and permission requests to specify the level at which the app is intended to run, and the permission level that is assigned to the app. The app permission request scope indicates the location within the SharePoint 2013 hierarchy where a permission request will apply. SharePoint 2013 supports the following permission request scopes:

•SPSite Defines the app permission request scope as a SharePoint 2013 site collection.

•SPWeb Defines the app permission request scope as a SharePoint 2013 web site.

•SPList Defines the app permission request scope as a SharePoint 2013 list.

•Tenancy Defines the app permission request scope as a SharePoint 2013 tenancy.

If an app is granted permission to one scope, the permission also applies to the children of that scope. For example, if an app is granted permission to a web site by using the SPWeb scope, the app is also granted permission to each list (SPList scope) that is contained within the SPWeb scope and all list items within each list. Because permission requests are made without information about the topology of the site collection where the app is installed, the scope is expressed as a type rather than as the URL of a specific instance. These scope types are expressed as URIs. Content database related permissions are organized under this URI: http://sharepoint/content. The following table provides an URI example for each app permission request scope.

http://technet.microsoft.com/en-us/library/jj219576.aspx

I highly advise you to glance at:

for full understanding of apps in 2013

http://technet.microsoft.com/en-us/library/fp161230.aspx

and also

planning (stratergy) for apps in 2013

http://technet.microsoft.com/en-us/library/fp161237.aspx

What your refering to as complex is not really complex and is part of sharepoint standard practice, otherwise not many people would develop apps in the first place if there was no security involved!