Currently, in the Spotfire Library, our clients store their Analysis files in a folder which is not visible to other clients (i.e. users) because their account is set as the owner of the folder. However, if I, as a developer, log in with Administrator account, I am able to see and open all of our client's Analysis files.
is there any security measures I can implement so that our client's Analysis files, stored in the Spotfire Library, are not accessible even for Administrator accounts?
I reached to TIBCO about that, and it turns out that this feature does not exist as of now. If anyone is interested, please upvote it here -> https://ideas.tibco.com/ideas/TS-I-7252
Related
Is it easy for people to find "public" google sheets/docs?
Context: Storing some semi-sensitive data (individual user info, of non-sensitive nature) for an app beta-test in google sheets. Planning to migrate to some DB in the future, but for now, just using JavaScript to pull the data directly from the google sheets (since there are visualizations being dynamically updated by the sheets).
Yes, it's easy to get information. Search engines may index and cache the information. Then, there are bots, crawlers and scrapers. Do NOT put (semi)sensitive information in public. Implement google-oauth properly with google-sheets-api to get information. You can also use service-accounts
Yes, it can be easily accessed.
According to the official Google article Share files from Google Drive: when you set your file's General Access setting to public:
Anyone can search on Google and get access to your file, without signing in to their Google account.
What you can do:
In the case of your app beta-test in google sheets data, you may want to reconsider to change your file's General Access setting to one of the following (in descending order of security):
Restricted - Only people that you manually give access to can view or edit your files. When you click the share button, a prompt will show and you may manually add the users who can view or edit your files:
Afterwards, you may select a role for those users and then they can be notified afterwards through email.
On the other hand, you can share the link to others. A prompt will show like the one below if you send the url through Google Chat:
You may opt to select Don't give access which will result in the following view on the other user's end:
This would mean that if unauthorized users get hold of the file URL, they will still need to send an access request. If other users submit the request, an email notification will be sent to your mail inbox. Other users who also own the file will also be notified by mail.
Your Organization - If you use a Google Account through work or school, anyone signed in to an account in your organization can open the file. If you are an administrator in a work or school workspace, you may set how members can share content within the organization. The administrator can prevent the sharing of content with group members outside your organization. If external sharing is prohibited, only group members who are in your organization can access the group's shared content.
Anyone with the link - Anyone who has the link can use your file, without signing in to their Google Account. This option is least recommended because if the URL is leaked to unauthorized users, they can easily access the file.
References:
Share files from Google Drive
Share content with a group
Don’t make it public unless you want the public to see it. Use oauth to access.
I'm currently working on migrating a big company's data from DropBox to SharePoint and i can't quite decide on how to structure the whole SharePoint environment.
So as you may know DropBox has an admin section where you add your members, groups and content to share and it is pretty straightforward on how to implement simple things and by that, i mean that you get your members on some groups and then you share specific folders (from your content) to that group directly.
As of SharePoint now, i found out that it has more or less the same functionality but it really gets pretty inconvenient on how to implement this. I created a new site, then i created my groups and added some users to them, then i created as many document libraries as my shared folders were on DropBox, i stopped inheritance from the site and added groups directly to the document libraries. All that, took me quite a while, more than 8 hours, for 30 document libraries and 20 groups mostly due to the back and forth i had to go through settings, permissions, libraries etc.
Would it be, let's say, more practical or rather make more sense to create a new site for every shared folder i have on DropBox and add members directly from the site's homepage?
What would you do for such a case?
Thanks in advance
PS. The migration tool that SharePoint admin center provides it comes pretty handy and it works good, but transfers data quite slowly.
TLDR: Use sites, not libraries, for different user groups.
SharePoint makes the following things easy:
Sharing a whole site (by inviting people as members (edit) or visiors (read))
Sharing a single file (with a person that you don't want to have access to the other stuff on the site)
SharePoint makes the following very hard:
sharing specific libraries with distinct groups of people. This requires a lot of setup work and is a maintenance nightmare. You also need to be an administrator of the each site and know where in the depth of the SharePoint settings you can find the switch to break permissions and invite other people to a library.
It is not recommended practice to share libraries like that.
In your scenario, you would be served better with individual team sites using O365 groups. Then add members via the home page sharing button. The site should be the permission boundaries and these permissions should not be broken for any site content.
If the need arises to break permissions for certain content, it's time to move that content to a separate site with its own membership groups.
Using O365 groups, any site membership can then be viewed, managed and audited in the SharePoint admin portal and the M365 admin portal. No SharePoint knowledge or SharPoint site access is required for admins to manage membership. Membership assignment can also be automated with various tools like PowerShell or Power Automate.
Users can see only the sites they have access to, and will not suffer the bad user experience of clicking a library, only to get an error message for "You do not have access".
My SharePoint Environment is SharePoint 2019 On Premise
Is it possible to show alert message on the page or popup window, when user SHARE the document on the Document Library.
When we Share the document, whether or not we could modify the mail alert template/ Content.
Thanks
By 'share', I assume you mean you want to show a message anytime someone edits the permissions of a document. (Since technically, I could 'share' a document by emailing someone the link to it.)
To my knowledge, the only way to achieve this would be to build a custom-code (SPFx) solution which uses API's to interact with the document's permissions granted via app-only access. And block users' ability to access those documents in the traditional way through SharePoint. This would give you full control over the UI, and prevent users from granting access (sharing) elsewhere.
Another option you might investigate is Azure Rights Management. Sensitivity labels applied to documents/libraries can be configured to automatically display headers, footers, watermarks, and even encryption when they are accessed. Exchange can also be configured to display a 'tip', when it detects users are trying to email a sensitive document. Full disclosure: I have only worked with these features in SharePoint online and I'm not certain of their capability in an on-premise environment.
I would like to be able to supply external users (customers, potential leads, suppliers) across organisations and internal users inside my organisation with documents.
The documents should be organisable per user individually. E.g. Customer A should be able too see documents for the product he bought, not more and not less documents.
No further functionality is currently needed besides that.
Is SharePoint the right tool for that job?
If not what other tools can you recommend from your experience?
I see you tagged SharePoint 2019, I'd advise against using on-prem SharePoint for Sharing documents externally. It is possible, but to do it securely is complex and expensive.
O365 on the other hand is pretty simple and the security is already implemented for you. You can determine the level of access that your external users have and you can extend that by using additional tools provided by Microsoft Information Protection.
You can secure access by forcing guests to login or simply have anonymous links. To add to that you can automate your publishing processes using Power Automate, the O365 workflow.
Take out a trial subscription and make sure it meets all your requirements first.
In Moss 2007 you have the ability to set the target audience for each individual web part within a page. Is there a way to preview how the page will look to another user without logging in as that user? What I am looking for is a way for someone with full control/design permissions on a site to be able to preview how the site will be displayed to another user. Any suggestions?
I have a few test accounts that our IS department uses to preview pages, however we do not allow non-IS departamental staff to use those accounts. Those staff members only have access to their one account. So, if a user makes changes the target audience on a web part on one of their pages, right now they have no way to preview how the page will look to someone else other than asking someone else to login & watching over their shoulder. I can't give out the account information for the test accounts, nor can I create new test accounts.
Thanks!
Edit: I have the ability to preview. The problem is that other users with full control of a site can't preview the page. Here's a scenarios: In my school division each school has a site. The principal has full control of his school's site. On the landing page, he wants all the school announcements to be visible. However, some should only be visible to teaching staff, while others need to be visible to the students. He uses audience targetting but cannot preview to see at a glance that the targetting is correct. A lot of the users are not computer savy so things need to be as simple as possible. Also, that was just one scenario, there are other scenarios that are not divided by school. There are many users with full control of a site with different requirements - so it's not feasible to create test accounts for all scenarios.
First I don't think it is possible to have a preview feature if you are using NT security. Maybe it is something you can do with forms authentication but I never used it.
On that subject. I think when you are developing new features or integrating stuff on a MOSS/WSS server you need a little flexibility.
With what I see you have to following things you can do. It is surely more cost effective than developing a custom solution. I assume you are using NT Security.
User accounts : Ask your domain administrator to have dedicated user accounts to play with.
Virtual Machines : Ask to have some virual machines to be able to play with that server combined with tests accounts
Sandboxed environment : Ask your IT dept to create a sandboxed MOSS environment to have to possibility to replicate your actual MOSS environment and create custom user scenarios.
Edit: After re-reading the question I released that you want the users to be able to preview a page. I think you will need to look into writing a preview control that uses Impersonation to load the page. Not sure how feasible this is, but surely someone has created a preview feature. Sounds like a pretty common scenario to me.
Old Answer:
Could you not fire up a non MS browser such as Firefox, which will prompt for the username and password.
You can then just clear the session cookies to be prompted to log in as someone else.
This is the technique I used for an ASP.Net site that used authentication against the domain in a similar manner to SharePoint.
Alternatively, you can create a control/webpart that hooks into the audiences for the site and displays the audience membership to the user (maybe from the GetMembership call). This does not preview the site, but it will give your editors a heads up on who is in each audience. Something that will help them get the audiences correct.
We have made a similar webpart for security group membership.
I think there are two approaches you can take:
Do make use of test accounts to preview the pages. You can ease the "pain" to log in as another user by making use of the RUNAS command (http://technet.microsoft.com/en-us/library/bb490994.aspx). So it's possible to just create a shortcut on the desktop that opens a browser making use of another account's credentials. Only that browser instance will work with the test account.
Make a copy (or more copies) of the page that you want to preview, store it in a secured site (so it's only accessible for the principal for example), and tweak the Audience Targetting properties of the web parts on that page/pages.
For previewing target audiences only, the only way to do it is to create a target audience that runs based on a properties in the SSP User Profile Properties.
You can then have a control that allows the editor to change the value stored thier profile, re-compile the profiles and voila (for some description of voila) the user will have change thier audience targetting values to something else.
This would need quite a bit of coding and some thought put into the rules for the audience targetting.
At the end of the day, the most cost effective way is to push back to your infrastructure guys for an account solution that will allow you to have an "reader" account people can use for this function.