The same is true for forms that are Public (hidden). It is no problem getting at the data in those forms. The same goes for records in forms. Row level access on top of form access is your friend there. The safest measurement of whether you are doing it right is to ask what a user can do at the API level. Anything anyone can do through any API call they can probably find a way to do through the mid-tier (admittedly, there may be some exceptions).
The thing I commonly see that bothers me the most are publicly writable fields on publicly accessible forms (whether the form is hidden or not), since any authenticated user can modify the data contained in those fields, for every record they can access. It begs the question, "Does anyone know a way to pull the metadata, for publicly writable fields, on publicly accessible forms, while authenticated as a non-administrator user, with only access to a mid-tier interface?" Axton Grams On Wed, Jun 25, 2014 at 9:59 AM, Mueller, Doug <doug_muel...@bmc.com> wrote: > ** > > Folks, > > > > I cannot be strong enough in repeating the statements that LJ has made. > > > > Show/hide a field or active link workflow to check permissions IS NOT > SECURITY. It is screen fiddling. > > > > Security is accomplished by PERMISSIONS. If someone has permission to a > field (read or write), they have > > access to the data in that field. Whether they see it on the screen > directly or fiddle with javascript or write > > an API program or use Web Service calls or whatever they do, they have > been given permission to the field > > so they can see/change the data in that field. The application gave them > permission to access the field. > > > > If you do not want them to access the field and its data, set permission > to NOT ALLOW them access. That is > > the only way you can enforce security. > > > > So, the issue here is not a security issue. It is really not something > that should be a concern/issue at all. You > > have given them permission to the field. If someone can edit and play > with javascript, they can write a web > > service call or code a small API program (even using .net or perl or > something similar as there are API wrappers > > for these environments). > > > > Just something to keep in mind with any definitions you are working with > where the data is sensitive. > > > > Doug Mueller > > > > *From:* Action Request System discussion list(ARSList) [mailto: > arslist@ARSLIST.ORG] *On Behalf Of *LJ LongWing > *Sent:* Wednesday, June 25, 2014 7:41 AM > *To:* arslist@ARSLIST.ORG > *Subject:* Re: Change Java script to modify form in web- Security issue!! > > > > ** > > Sahil, > > This isn't a security issue. If the user has permission to the field, > they have permission. Your workflow to hide the field is just a UI tool to > make the interface look the way you want, 'hide' is not a security feature. > > > > So, while you may not want them to modify the Java Script, they certainly > have the ability...so if you need to manage this as a security issue, you > need to modify the permissions on the field and only allow the users that > should have access, or build filters to prevent certain situations from > occurring. > > > > On Wed, Jun 25, 2014 at 8:34 AM, Sahil <pathania.sa...@gmail.com> wrote: > > ** > > Hello Friends, > > > > We have fields on the form which are visible and hidden. Now some fields > are set to visible and hidden by active link workflow and few are visible > based on the user permission. > > > > Now if user open the form in web browser, then he can change the java > script and make the field visible from hidden and submit or query the form? > > > > How can we stop this from happening, so that user cannot modify the java > script from browser. > > > > When you open the form in web, pres ALT+ CTRL+ i then right click on the > java script below and select edit as HTML. > > > > > > Thanks a lot > > > > sahil > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > > > > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _ARSlist: "Where the Answers Are" and have been for 20 years_ > _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org "Where the Answers Are, and have been for 20 years"
