The documentation page is 100% silent about all the permissions.
How do we know what each permission is meant to do?
I am specifically interested in the data/read/scroll/clear permission
As you mentioned, the documentations do not have this information.
Best bet would be to search through the codebase to get the corresponding action class and then deduce from that.
For the given action data/read/scroll/clear, this is what I found.
https://github.com/opensearch-project/OpenSearch/blob/0ba0e7cc26060f964fcbf6ee45bae53b3a9941d0/server/src/main/java/org/opensearch/action/search/ClearScrollAction.java#L40
The permission is for clearing the search contexts associated with specified scroll ids.
Related
Problem
I'm trying to provide my users with an alternative to purchasing my iAP by allowing them to share that they're playing the game via facebook.
However, when the composer view controller loads the content is editable by the user. Which, for profitability sake is a bad thing. They could remove the entire message and still receive the perk that they receive for sharing. Thus, ruling out that way of marketing.
I'm curious as to two solutions.
Solution One
Force Read-Only ?
Solution Two
Cancel the sharing and display an error message if the sent message is not equal to the initial text/images.
Also, if it is not possible for them to remove the image and/or url then I don't really have a problem with them adding their own text. However, if they can remove the image/url then there is an issue.
Thank you for reading.
Restricting/enforcing what to share by the user, in any way, is not allowed in the Facebook Platform Policy. See also point 2 of: https://developers.facebook.com/policy#control. You can't make the share dialog read-only and you should not check if they shared the content you have provided.
With the second solution; you might also be hitting a policy restriction. You should not incentivize people to share in order for these kind of promotions. See rule number 5: https://developers.facebook.com/policy#properuse. This might be an more difficult issue though, policy wise.
You can let people share an open graph object; either generated from your app or directly one that you (or FB) is hosting, with an open graph url. For that, see https://developers.facebook.com/docs/sharing/opengraph and https://developers.facebook.com/docs/sharing/best-practices.
I continue to get a "HTTP/1.1 403 Forbidden" response from a PUT request to /d2l/api/lp/1.2/courses/7917 . This may be a permission problem with the user/role that I'm using, but I can't figure out what specific permissions may be required. Can anyone point me to a list or matrix of valence routes and required permissions? Or, answer for this specific one?
The same appid/userid/username works for the GETs associated with the same path.
confused...
cwt
The permissions associated with API calls should mirror the permissions you'd have to have if you were to perform the relevant function through the Learning Envrionment's web UI. You can think about this problem in two ways:
Frame the question in terms of a user role: identify the class of users you'd reserve this ability for in your existing configuration, and ensure that a user of that role can make the call through the API as you'd expect.
Frame the question in terms of an abstract single user: start with a role that has no privileges and add permissions until you arrive at only the ones required for the API call. This is not a trivial exercise, and the first way is far more useful in the long run.
In this particular case, because the API requires you provide a complete course offering set of properties when you want to update it, you have to have permission to alter all the properties in the set (under the Manage Courses tool). You also need to be able to see the course info in the first place, so you need to have Course Management Console > See Course Info as well.
You're probably safest to look at the permissions array in the Manage Courses and Course Management Console tools for the user roles that would do this thing in the web UI and make sure that the users employing your app also have a similar permissions array specified in those tools.
I have a Google Spreadsheet containing a script that I wrote. The script updates a per-person sheet named after the logged in user, or creates a new one if it's not there yet.
I shared it in "can edit" mode with other people, expecting the code accessing the user name to work as it did in my case, but apparently it doesn't.
Google Apps Script seems to contain three ways to get the name of the current user:
Session.getActiveUser()
Session.getEffectiveUser()
Session.getUser()
and all of them return the empty string when I'm not the user running the script.
(Btw I'm having a hard time to tell the difference between them...)
Considering that I'm sharing this spreadsheet in read/write mode, I would be a bit surprised if this was an intended security method... it's not like I don't know the emails of the people accessing the spreadsheet I've explicitly shared with them... Plus, Google is asking for permission anyway, couldn't it ask for permission to access the user name as well??
Is there a way around this?
Is there a way around this?
These methods only work if you're using a Google Apps account and you're on the same domain as the user. If not, then there's no way to get the user id. AFAIK Google removed this feature completely for regular accounts. You may try to argue with them opening an issue here.
I have a site at http://moss/sites/Electronics/Laptop
I have given users contribute permission on laptop site but still when they try to edit the page they are getting access denied, I have checked the permission level and all permissions are fine bt still users are not able to edit page.
I gave them read permissions on Electronics site and now they are able to edit the pages. My question is why we need to give them read permission on the top level site? What we don't want users to go to the top level site at all and want them to have an access on subsite only? Any idea?
Thanks,
Does the user have any access to the child site before you granted access on the parent? If not, this is likely because you're using some reference to list data from the parent in the child. If the user has no access to the parent and the child is trying to access that data, it will fail and the user will get access denied regardless of their permissions on child.
If they had access but just couldn't edit, this could be a completely different problem but it isn't typical out-of-box behavior. I would still be suspicious that something from parent is being used in child to cause this contention.
I've just discovered this in my 2010 installation. User has rights on a library, but Limited Access at the site level. Granting them Contribute at the site level resolved the issue, but this causes a long list of other issues relating to security. That's an end-user\training issue I need to work on.
Just my $.02
What would be the best way to go about giving users the ability to share a private link that enables anyone who clicks it to view a certain page/document/item that have privacy restrictions in place?
In my case:
A User creates events which are limited to certain groups of relationships in the database (namely: friends, friends of friends, etc.) I have a :before_filter in the event controller that checks the eligibility of the current logged in user to make sure that that user has permission to see the event. If they don't they get booted to the root page with an error message.
However, I want a special scenario to exist where a user can create an event with those same privacy settings and IN ADDITION, be able to share a special link with his or her friends via e-mail, facebook, etc. Those users do NOT need an account (but will need to make one in order to sign up for the event). This is important because there is also a :before_filter in the application_controller which makes sure a user is logged in.
I'm thinking there is something I could do with routing here... Right now I just have the simple /events/72 setup. Should each event have two different links: a normal one, and a "special code" version which enables them to bypass those two :before_filter?
What are people's thoughts?
I agree with David Lyod's answer (separating this concern in a different controller).
But for creating the hash I strongly recommend you salting the hash with some secret phrase.
require "digest"
Digest::SHA512.hexdigest("#{created_at}#{user_id}.mysupersonicsecretSALT")
Doing this it is not possible, without the knowlegde of the secret phrase, to calculate the hashes and test them against your system until it hits an existing one.
If you're handling sensitive data you should not be lazy.
Cheers,
Lukas
I would have a separate controller that uses a hash value to reference the event.
Something simple like the created_at + user_id hashed to create a unique reference.
You could also simply skip the check on a certain action but I would much prefer the first solution .