Þetta er annar póstur í mínum á að fara röð um hvernig á að nota jQuery með SharePoint.
Ef þú vilt læra meira um jQuery, Ég mæli: jQuery í Aðgerð með Bear Bibeault og Yehuda Katz.
Einn af the fyrstur hlutur ég hélt, þegar ég byrjaði að leika í kring með jQuery, var hvort við gætum notað það til að tryggja SharePoint útsýni. Svarið er "nei" (or at least, Ég ætla ekki að segja að það er hægt). Hins, það er vissulega hægt að gera það erfitt fyrir fólk að sjá ákveðna sýn.
Ég byrjaði með sandkassa umhverfi mitt þegar vinna á þessu. Ég skrifaði um það umhverfi hér: Fljótur og Þægilegur: Búa til eigin jQuery Sandbox þín fyrir SharePoint.
Að "tryggja" útsýni, Fylgdu þessum leiðbeiningum:
- Búa til mynd sem þú vilt að tryggja. Ég gerði það og kallaði það "Tryggt View".
Þetta er það sem það lítur út eins og þegar það er ekki "öruggur":
- Bæta við efni ritstjóri vefur hluti á síðuna útsýnisins er með bragð sem lýst er í sandkassa grein (i.e. bæta "birting = Deilt&ToolPaneView = 2 "á slóðina).
- Reikna út SharePoint _spUserId með því að fylgja þessum brjálaður skrefum, trúa eða ekki:
- Bættu eftirfarandi JavaScript til CEWP þitt í númerið ljósi:
Ég hef sett með að viðvörun(_spUserId) lína í það að sýna fram á hvernig þetta er í raun ekki "tryggja" útsýni, en einfaldlega að gera það erfiðara að sjá. Meira um það í smá stund.
Grundvallaratriðum, jQuery is looking for an iFrame on the page who has an attribute that contains “Secured View” in its value. Once it finds it, we check to see if the current user is “13”. If it is, we walk up the DOM to a <TR> tag (which I figured out by viewing source and tracing it) and then replacing that TR tag with my message. I really don’t know how robust this is (I’m very suspicious, í raun), but it worked in my sandbox. If I find a better way, I’ll blog about it. This is the result:
I click the OK button and the data is replaced with a big red message:
As you can tell, the way I’ve implement this “security” solution is to allow the web part to render itself. After it finishes, I overwrite its content with my “No view for you!” message.
Despite the fact that it’s not really a “secured’” view, it’s potentially useful and with some clever work, it may eventually be securable in a more formal sense. The fundamental issue is that the client is getting all the data and then, only after it gets the data, it wipes it out. If the client is getting the data, a clever user can prevent the jQuery from running at all and see what he/she wants to see.
There are other drawbacks. This “security” approach is based off a _spUserId. We’d want to really secure based on the full SharePoint security model, or at least by user name. That becomes progressively harder, but I see some good stuff written on this subject, so I’m hopeful there’s a good answer to that problem.
The list of views themselves should be trimmed, if possible. I haven’t tried to figure that out. I assume it’s possible, but doesn’t really solve the fundamental security issue because someone could still just type the URL of the view they want (if they knew it). Hins, trimming makes sense. It’s a good usability feature and it helps to obfuscate things. If an end user doesn’t know that the view event exists, they probably won’t try to use it. Stundum, that’s good enough.
With luck, I’ll have more to write on this subject over time.
</enda>
Gerast áskrifandi að bloggið mitt.
Fylgdu mér á Twitter á http://www.twitter.com/pagalvin