I am facing issue while accessing taxonomy for anonymous users, for windows authenticated users its working fine. This taxonomy is used for building site navigation and below is the code I am using to get the records
var navTermSet = TaxonomyNavigation.GetTermSetForWeb(site.RootWeb, StandardNavigationProviderNames.CurrentNavigationTaxonomyProvider, true);
This code is wrapped under run with elevated privilege and this code returns 2 term set and under each term set there are many terms presents, but if I run this code under windows authenticated user it will return all the terms else it will return only 2.
Under each termset it will show count as 0
Below verification I have done from my end
1) Site is anonymous and taxonomy hidden list is having anonymous enabled and provided view permission for everyone
2) Added MMS app pool account, Web app pool account to MMS db
3) Provided full access to both the account in term store admin access # central admin(Service)
Can any one please guide me how I can fix this
Regards
Anand
I have deleted the site collection and recreated it, then it started working.
Related
Sorry if my English is weird.
I would like to know how a non-admin account can use the Admin SDK.
If you have any suggestions, please let me know.
I'm developing an add-on for an elementary school using Google app script.
I want to limit the API by student, teacher, grade, etc. So I need to get the organization information.
There were a few other similar questions, and apparently it would be impossible to try to do it normally.
When using the Admin SDK, Google will display an acceptance confirmation screen to the user.
Once the user agrees, Google gives the app an access token that is valid for a short period of time. I'm thinking that I can do this by using that access token. Is this approach dangerous from a security point of view?
I'm sorry for the lack of explanation.
I'm currently developing a google slides add-on for an elementary school.
It's supposed to display a SPA made with vuejs in the sidebar and let you manipulate it.
For example, we can manage a whitelist of organizations that can use this application in advance, and not allow organizations that do not match the whitelist to use it.
If the organization is managed by school unit, access control can be done by domain, but in some areas, the organization is managed by city, so access control by school unit cannot be realized...
Also.We want to do the following if we match the whitelist.
The functions that can be used by teachers and students are
different.
The buttons can be changed depending on the grade level of the
students.
Automatically enter student names and class names on slides.
Use an organizational structure to manage the school and students. (https://support.google.com/a/answer/4352075?ref_topic=4390186&hl=en)
We think we can achieve this by using the Admin SDK to get organization information
Answer
It is not possible to use Admin SDK with a non-admin account as Google says in the documentation: This API gives administrators of Google Workspace domains (including resellers) the ability to manage devices, groups, users, and other entities in their domains.
However there are two workarounds for your problem, but you would need to use an admin account to configure the scenario.
Initial approach
Get the user that is running the application with the class Session and the method getActiveUser and getEmail: var email = Session.getActiveUser().getEmail();
Get the organizational unit that each user belongs to. With this information you will be able to filter users and display different options in the add-on. The main problem is that you need to use AdminDirectory.Users.get(userEmail) to get the organizational unit, and it needs the following authorization scope: https://www.googleapis.com/auth/admin.directory.user.readonly.
Solution 1
Create a Spreadsheet with all the users that are going to use the add-on and its organizational unit
Use List all users to get all the users in a domain and write each email in the first column.
Use AdminDirectory.Users.get(email).orgUnitPath to get the organizational unit and write it in the next column
Finally, when users use the add-on, search the email of the active user (Session.getActiveUser().getEmail()) in the Spreadsheet, take the row number and get the value of the organizational unit that is in the second column.
Solution 2
Create a custom admin role and assign it to every user that is going to use the add-on. You must be signed in as a super administrator for this task. You can do it here and select Users -> Read,
Assign the new role to each user creating a role assignment
Finally, users will be able to use var organization = AdminDirectory.Users.get(email).orgUnitPath
I'm following the "Gauth authentication" portion of Djangae's documentation but I'm running into some unexpected behavior.
I've configured urls.py and settings.py as specified by the documentation (the current settings are mostly a result of using the Djangae Scaffold) but at no point are users prompted to authenticate using or link their Google account. I've tried un/setting DJANGAE_CREATE_UNKNOWN_USER but this has no impact.
I've also tried running commands inspired by sitepackages/prod/djangae/contrib/gauth/tests.py in my local shell in order to verify that the back-end configuration is correctly configured and that users can actually be authenticated against AppEngineUserAPIBackend but that fails because my User model (djangae.contrib.gauth_datastore.models.GaeDatastoreUser) seems to be missing required attributes: AttributeError: 'GaeDatastoreUser' object has no attribute 'user_id'.
So, am I misunderstanding how this is all supposed to work and must take some additional steps to get Google Sign-In working? Or have I (likely) misconfigured my application? (I'm happy to include genericized versions of my config, but as I said, they've come directly from Djangae Scaffold or the documentation.)
UPDATE: Interestingly, if I remove the --headless flag from my Behavior suite config, I see the expected behavior. The browser (Chrome) is being redirected to https://accounts.google.com/Login?continue=http%3A%2F%2Flocalhost%3A8080%2F
Environment:
Djangae (0.9.11)
Django (1.11.19)
It turns out that this is the expected behavior. In the local sandbox, users are prompted for an email address and (by default) a "user" is created for them and they are automatically logged in.
From App Engine's "Users Python API Overview" document:
Google accounts and the development server
The development server simulates the Google Accounts system using a
dummy sign-in screen. When your application calls the Users API to get
the URL for the sign-in screen, the API returns a special development
server URL that prompts for an email address, but no password. You can
type any email address into this prompt, and the app will behave as if
you are signed in with an account with that address.
The dummy sign-in screen also includes a checkbox that indicates
whether the dummy account is an administrator; that is, whether the
account has the the Viewer, Editor, or Owner primitive role, or the
App Engine App Admin predefined role. If you check this box, the app
will behave as if you are signed in using an administrator account.
Similarly, the Users API returns a sign-out URL that cancels the dummy
sign-in.
The unique ID for a User object in the development server is
calculated from the email address. Two unique email addresses always
represent two unique users in the development server.
Personally, I think this design is very flawed. I don't know what Google thinks about the Twelve Factor manifesto, but this behavior is a flagrant violation of article 10 (Dev/Prod Parity), which is summarized as "Keep development, staging, and production as similar as possible". I see no reason why the full auth/redirect flow wouldn't work in the local sandbox and, at the very least, users should be able to opt into it. (I would love to find out that this is an option.)
The most concerning part about this conditional behavior is that the user object's API is different, which is why I was seeing the error mentioned in my question ('GaeDatastoreUser' object has no attribute 'user_id'). The local user also has no nickname method.
I'm trying to do new development on the FB platform post-Cambridge Analytica. Two days ago - i.e. after the review and restrictions started - I created a new FB app and a new Page. Using the Graph API Explorer, I can call /me/ on my new page when the selected app is the Explorer app:
However, when I use my new app, I get the infamous OAuth error about "non-active apps or apps that have not recently accessed this data":
The page access tokens for the two calls have the same permissions, the defaults Graph API Explorer uses:
I'm aware of this question that deals with the general case of this error: Why does Facebook Graph API say my account is non-active?
However, some of the answers to it hint that either having "a first-party relationship" is what determines if I'm allowed access, or not asking for specific fields; and it seems to be about applications that worked before the drama and stopped working after. My app and page are new, created and admined by my account, I can hardly have a more first-party relationship than that; and I'm not asking any fields that aren't publically available for the page anyway. I've tried publishing and unpublishing the page, as well as having the app be in development or live.
Is there any way to actually start a new FB app before the dust settles? Or does "not active or hasn't recently accessed the data" mean only apps that were live and connected to the given pages before the clampdown can work?
Is there a way to export the list of clearcase/quest users?
I saw the utility in the "user administration" program but it export everything and I only need the users that use clearcase/quest for the last year.
thanks!
It seems that such an export should differ between ClearCase and ClearQuest, since only the latter has a user database (while the former -- ClearCase -- relies on system account).
You can check, for Clearquest:
"Using the ClearQuest API to access a user database"
"Querying Rational ClearQuest user databases"
ClearCase users are usually registered in a Windows group dedicated for that application (like "ClearCaseUsers").
So you could try and list all the users of that group (or any group you configured ClearCase to use) in order to get the list of ClearCase users.
What kind of list are you looking for?
You can use ClearQuest OSLC CM REST API found here (https://jazz.net/wiki/bin/view/Main/RcmRestCmApi) to issue an http request and get a XML list of all ClearQuest users:
http://localhost:8080/oslc/cqrest/repo/7.0.0/db/SAMPL/record/?oslc_cm.query=&rcm.type=users
Where:
http://localhost:8080/oslc/cqrest/repo/7.0.0/db/SAMPL/record/
is a sample base URL. You would have to figure out what your base URL is. The following API documentation helped me figure that out https://jazz.net/wiki/bin/view/Main/CqOslcV2
You just submit that request through your browser (not IE) or in code and get back an xml response with the list of users.
I'm building a lightweight web interface to SSRS where web app users are mapped to web app roles, which in turn are mapped to SSRS users.
The reason for this convoluted scheme is not up for debate: In short, AD groups can't be used, the site uses Forms auth and there are a fixed number of roles.
Web Role | SSRS User
Admin | AdminUser
Supervisor | SuperUser
User | BasicUser
Guest | GuestUser
The goal is to enumerate all reports a user has permission to view, and allow the user to view the report with the ReportViewer control.
More importantly, it's to simplify the UX for users, both admins and the rest: preventing admins from having to use the Report Manager website (ie, selecting checkboxes rather than hand-typing which web-role-users have access to which reports), and providing a simple UI from which users can see and execute all their reports.
Everything works OK when the user is the AdminUser.
However, I'm having difficulty calling the web service when the user isn't included in a Policy on the Home/Root folder with at least the Browser SSRS role. (The permissions granted to user 'computer\username' are insufficient for performing this operation.)
This is problematic for a couple reasons:
If every user must be a Browser to connect to the web service and enumerate reports they have access to view/execute, then all users will have access to all new reports/folders by default. (Children automatically inherit new permissions)
If a report exists in a nested folder that does not inherit permissions and the user is not a browser of, but the user is a Browser on the nested report, ListChildren() will not return that report.
It seems this leaves me with 2 less than ideal options:
Don't call the web service with the different users. Instead, enumerate reports with ListChildren() using only the admin user. Then, for each report, call GetPolicies(), and from that collection of policies, determine what reports the user is able to view.
Make the call with different users. Live with the pitfalls of newly-published reports being accessible to everyone by default, until permissions are changed. Also live with the pitfalls of nested reports not showing unless the user has access to that path. If an admin wants a nested report within a folder with explicit permissions to be available to a user who can't see that folder, the policies on all ancestor folders and their children must be modified.
#1 is obviously very unwieldy and inefficient. But #2 has significant drawbacks and becomes just as onerous & inefficient when setting permissions in certain situations.
Is there a better way? Have I missed something obvious?
[edit]
A 3rd option is to query the ReportServer database directly using a query like this. This has the benefit of returning everything the user has access to, regardless of whether or not it exists in a subfolder the user cannot access (aka, cannot use the web service's ListChildren method to retrieve). However, if using AD groups, I would have to know which groups the user is a member of, whereas the web service would do this for me. This option feels like a bit of a hack to me, but it could work.
As it turns out, we ran an end-route around this issue by dropping the requirement to restrict report access by web role, and made the path we query in the web service a web.config setting that can change, thus allowing report authors to 'hide' reports in a parent folder if the need arises in the future.
The best solution would have been to query the ReportServer database directly.
However, the client changed their mind & didn't want to restrict reports based on web user role in the end, so problem solved!