There are various places in my Sharepoint generated web pages where element IDs are assigned values by Sharepoint with the prefix "ct100".
How safe is it to refer to these IDs in my javascript?
How static are they?
How likely are they to change for any reason?
Is there any documentation that discusses how they are generetad and answers the above questions?
Thanks,
George
"Safe" is relative here and depends on the specific page and controls involved.
The individual IDs that look like ctXYZ are generated automatically by the parent ASP.Net Naming Container when the control has not been explicitly assigned an ID - that is, the ID is auto-generated like ct001, ct002, etc, making sure not to create duplicates.
The final Client ID - which is assigned as the id attribute in the HTML - is the made up of joining all the IDs of the control and all ancestors with underscores; thus the stability of a single Client ID is affected by multiple controls.
The generated Client IDs are generally guaranteed to remain stable only if the Control Tree is always re-created in the same way - this holds true in many cases, but it is not absolute. Dynamically adding or removing controls can easily break this assumption.
ASP.Net 4 (or 4.5?) introduced a different ID mode - primarily "Predictable", see the Naming Container link - but I do not believe that SharePoint uses this new feature anywhere; and it's definitely not used for IDs that contain ctXYZ components.
Based on research, the safest approach is to use css and jquery to identify and manipulate the "ct001" elements. I have tried this approach and it appears to be working fine.
Related
The documentation for tasks seems to imply that the POST method uses name/value pairs as the data payload (I'm assuming for a content type of application/x-www-form-urlencoded). Can it accept JSON instead, using the same format as the data returned from a GET call for tasks?
Also, the Memberships field is supposed to contain an array of projects and sections. There's already a Projects field for a task - do those projects need to be duplicated in the list of projects for Memberships or can just the sections be included?
Yep, it's totally possible to use a JSON payload (with the correct Content-Type: application/json) - in fact, in a number of scenarios - like this one - it's considerably easier.
I don't recall off of the top of my head the right way to get this going with form data (if I recall, we might have an outstanding bug filed about it :) ), but with JSON, you should be fine if you specify the project in both locations. I don't think you can get away with not specifying any values in projects (unless you specify a workspace, which might work).
I don't think you can specify only the section. Finally, I think if you specify a different project in each location, it will put it into both: into projects in the "no section" area for whichever ones are in the projects property and put it in the specified sections for those specified in memberships
We currently design our solutions using a single form per entity. We have a current set of requirements where the 10 or so entities are similar in terms of functionality and data collection. Ideally we would like to have entity with 10 or so forms and dependent on a lookup value display the correct form on the click of a custom button.
I have previously worked with a supplier who implemented something like this displaying the correct form using the GUID (using the formid querystring parameter) on the load event using JavaScript. Although this worked 95% of the time, depending on the client machine it occassionally did not load the correct form due to timing issues i.e. the code had not properly executed by the time the form loaded.
Is there a best practice for using this kind of technique?
I guess my other options are
1) multiple entities
2) one form with tabs/sections that i show/hide on the form load
I am leaning towards implementing option 2)
Richard
The multiple forms inside of CRM 2011 is only for different roles. It is not designed to handle switching between forms based on entity attributes.
Granted what you are trying to do is possible, but you will encounter
issues and will need JavaScript to switch the user to the right form
type. You'll also cause the user to load the form twice each time (kind of ugly)
Another option is to use JavaScript to show/hide the proper elements
on the form (similar to 4.0)
Or you can just use multiple entities with a common JS file for any
kind of logic.
depending upon any field value you can switch the forms through JavaScript.
In JavaScript redirect page to url:
[serverurl]/main.aspx?etn=[entityname]&extraqs=etc%3d[entitytypecode]%26formid%3d[formguid]%26id%3d%257b[recordguid]%257d&pagetype=entityrecord
Where
entityname = entity name (e.g. incident),
entitytypecode=entity type code (e.g for incident it is 112),
formguid=guid of the form to which you want to redirect,
recordguid = guid of the record. If you skip id parameter, form will open in create mode.
I was wondering if anyone knows if the following scenario can happen.
Suppose I have dynamically generated a form that has check boxes for products specific to that customer. If the customer checks the boxes, the products will be deleted when form posted. The checkboxes are named after the productID.
Now my handler will check the response.form and parse the productID out, then delete the product from the database based on the productID.
Potentially could someone amend the post to allow other productIDs to be deleted, potentially everything in the product table by adding fake checkbox names to the POST?
If so, it would be easy to check prior to delete the productID is related to the authenticated user, and they have sufficient roles to delete, or to generate a nonce and label the checkboxes with that rather than their product ID, however I am not doing this at the moment. Any pointers to best practices for this would be good.
I have never considered this before, and wonder just how many people actually do this by default, or are there a million web sites out there vunerable?
Thanks
It is absolutely possible that someone could build a custom POST request with any key/value pairs (including product ID values) and submit it to your application. The fact that the checkboxes are not on the form that the POST is supposed to come from is irrelevant from a security perspective.
When thinking about web application security, the client is a completely untrusted entity. You have to assume that your JavaScript validation will be bypassed, your SELECT elements can be altered to contain any value an attacker wants, and so forth.
So yes, you should validate that the current user is authorized to delete any product ID submitted to this handler.
I'm not necessarily convinced that you need to go the nonce-obfuscation route. It is an additional layer of security, which is good, but if you are performing proper authorization I don't think it's necessary.
My $0.02
Yes this is a problem. What you are describing is an example of the "Insecure Direct Object References" risk as defined by the Open Web Application Security Project (OWASP).
As to how common it is, it currently (2011) ranks 4th in the OWASP's list of top 10 most severe web application security risks. Details of how to prevent this can be found on the OWASP page.
How Do I Prevent Insecure Direct Object References?
Preventing insecure direct object
references requires selecting an
approach for protecting each user
accessible object (e.g., object
number, filename):
Use per user or session indirect
object references. This prevents
attackers from directly targeting
unauthorized resources. For example,
instead of using the resource’s
database key, a drop down list of
six resources authorized for the
current user could use the numbers 1
to 6 to indicate which value the
user selected. The application has
to map the per-user indirect
reference back to the actual
database key on the server. OWASP’s
ESAPI includes both sequential and
random access reference maps that
developers can use to eliminate
direct object references.
Check access. Each use of a direct object reference from an
untrusted source must include an
access control check to ensure the
user is authorized for the requested
object.
Why not simply validate the values you get against the values you provided? Example: You have provided check boxes for items 1, 2 and 3, 9. The user posts 1, 2, 3, 4, 5, 6. You can find the intersection of the lists and delete that (in this case 1, 2, and 3 are in both lists).
Is there some definition around the attributes that are returned from the Lists.GetListItems? I am able to view the attributes retuned just fine but I am wondering if they would ever change?
Here are some examples of what I am seeing... #ows_Author, #ows_FileDirRef, #ows_PermMask
I would like to build some classes around these values and my concern is that if they are not published somewhere Microsoft may up and change them or some setting in Sharepoint may.
It is possible that they change as sharepoint (major) version changes. Every change is possible then.
Don't think it would happen in minor version.
However they may also change depending on what list you query. But fields your mentioned and many other fields are basic fields that every list will contain.
If you want to view field data yourself (for example, what Type they are), download Sharepoint Manager - it's invaluable tool for a developer.
These are internal field names for default SharePoint fields. Unless you explicitly change them, they will remain the same.
Micheal Yeager's blog has a table which describes these fields and their data types:
http://blogs.msdn.com/michael_yeager/archive/2008/11/03/reference-list-for-internal-field-names.aspx
I need to create some functionality in our SharePoint app that populates a list or lists with some simple hierarchical data. Each parent record will represent a "submission" and each child record will be a "submission item." There's a 1-to-n relationship between submissions and submission items. Is this practical to do in SharePoint? The only types of list relationships I've done so far are lookup columns, but this seems a bit different. Also, once such a list relationship is established, then what's the best way to create views on this kind of data. I'm almost convinced that it'd be easier just to write this stuff to an external database, but I'd like to give SharePoint a shot in order to take advantage of the automated search capabilities.
Proper Parent/Child in Sharepoint is near impossible without developing it yourself. There is one approach to that here: Simulate Parent / Child relationship in SharePoint 2007 with Folders & Content Types
(Note: This concerns SharePoint 2007. In 2010, Joins make this much easier)
Do it in a separate database, create a page(s) with controls that surfaces the data and run search over that. Loses quite a bit of the SharePoint features though.
Otherwise it may be okay to create a custom field control that will allow you to lookup the data in the other list.
The custom field control can be the one to "view" the related data.
I know we have done it for parent child relationships between pages on the same list. Not 1-to-N though.
Tough choice either way.
My vote is "to write this stuff to an external database"
You miss a lot of things in Sharepoint things like transaction support, referential integrity, easy way of updating (compare SQL), reporting (using Reporting Services and a SQL database)... see sharepoint as a way to store documents and simple lists.....
The argument for Sharepoint is if it is a small application, no requirements on support for transactions, no need to import external data etc...
When people say Sharepoint is a development plattform there is a need to define whjat they think a development plattform is.
The latest rumours about Sharepoint 2010 tells us that there will be support for SQL server based lists in next version ..... which I think will at least move Sharepoint in the right direction ....
Take a look at SLAM, SharePoint List Association Manager, an open source project my company created and actively supports. SLAM allows you to synchronize SharePoint data to SQL, including any relationships between lists. SLAM, in addition to being very useful on its own, is really a framework intended to allow developers to create their own complex data associations using what we call SLAM type profiles. We have one out-of-the-box type profile which is part of the open source project which actually allows you to make a SharePoint list hierarchical using the nested set model. For more information, see this page on our codeplex site.
I do this a lot just using sharepoint, using a framework called AAA (Activity,Assignment,Artifact), which allows you to use lookup columns to link an assignment or artifact to a parent Activity. You then build a web part page with connected web parts that allow you to filter all assignments and artifacts by activity. For example, click next to a submission in the submission web part, and all of the submission items attached to that submission will show up. Works great.
The other approach that you can look at using is persisting XML with a field in the item. This is the approach used by the Podcasting Kit (on CodePlex) to store things like ratings.
One possible method is to create a submission content type based on the folder content type and a submission-item based on item content type. Then you can store data hierarchically like in file system and also will work default views and search functionality.
Other way is to create lookup field that points to same list (list=”self”). This field will be used like reference to parent item and you will get list that contains recursively related data. To use this data programmatically will be ok but using views functionality will be little bit complex.
It's easy to do using a connected web part.
Create two lists:
Parent (Id, Title)
Child (Id, Title, ParentId)
Create a new sharepoint page, add DataFormWebPart (displaying Parent) and another one for Child, set both of them to filter based on a QueryString parameter (use that Parameter to filter Parent.Id, and Child.ParentId) voila, you can display parent-child relationships. Now, adding children is more difficult, and that's the part I haven't worked out yet.