Follow-up question to this. I am currently trying to set up a Web Application to display reports on an intranet site, using the intranet login to authenticate users, passing the authorization process to icCube. I'm trying to get it to work with a local install of xampp apache using basic auth and a local install of icCube. My scripts are based on icCube's live demo.
When I use the WebApp, passing login information for a user, the function GetAllReportNames() fetches all available reports from our icCube server. The problem is that "available" means every report: there are also inaccessible reports displayed. There are two problems here:
We couldn't find an option to manage access rights for reports, only for cubes and schemas. Creating a manageable schema for every single report is not an option, though.
The WebApp still displays reports which can not be loaded due to schemas not being accessible, be it due to authorisation problems or the cube not being loaded currently.
Is there a ways to manage access rights for reports instead of schemas/cubes, and is there a function to get rid of unavailable reports before the list of reports is displayed by the WebApp?
You can setup access rights to the "Docs" documents from the UI. They are similar to permissions you'll find on a file system.
Related
How can I restrict access to database Manager page, by a password, for Odoo / OpenERP? So only master admin can see this page.
I found a good module here:
https://www.odoo.com/forum/help-1/question/how-to-show-the-manage-database-page-for-particular-user-like-administrator-in-openerp-v8-57036#answer-64736
But the problem is this module does not support multiple databases!
Is there any other method or custom module to achieve that ?
You can override the '/web/database/controller' and put the condition to check whether the session's user is admin or not , if it's admin then return the original page which is returned by odoo else you can show your page showing that you can't access this.
You can use this module: Restrict access to Manage Databases to restrict access to the Manage Databases page.
After installing the module, you will only be able to visit the Manage Databases page (/web/database/manager/) if you are signed in as the Administrator (with user ID = 1) or you have Technical Features enabled for that user.
If you have installed the module and are unable to switch databases while logged out, you can add the db flag to your url to manually select the database that you want, for example:
yoursite.com/web?db=database2
Caveat:
This solution might be troublesome as you will have to install it in all your databases on the same instance.
The other solution will be to use nginx to restrict access to /web/database/manager to only your IP address or a range or IP addresses.
I am attempting to set up an IIS 6.0 application running on Windows Server 2003 to use impersonation in order to avoid having to give users direct read/write access to the shared folders where the DB and web pages are stored. Can anyone provide me with details of how this can be set up to work in conjunction with Windows Integrated Authentication?
So far, I can tell that the web.config file (not sure whether it's the correct one) has the two lines mentioned on this thread (Impersonation in IIS 7.0) to allow impersonation and use the Windows logon method. However, users are still prompted for a logon and then told they are not authorized to view web pages. They can view pages if we turn anonymous logon "on", but then their user credentials aren't passed on to the site and therefore they can't access most of it.
I'm fairly inexperienced, so I'm a bit lost here. Thank you very much in advance for the help!
Thanks to intervention from Microsoft (definitely worth the flat fee they charge per incident), we were able to identify the problem. Instead of using the network path to identify the website location on the "Home Directory" tab of the IIS properties, we were using the local drive path. That was all that needed to be changed.
Once we switched to the network path and added a dedicated service account to "Connect As...", impersonation started working right away. Users pass their logged on credentials via integrated authentication (no logon required) and the service account takes care of executing their actions on the database file.
Access to the shared folder is limited to a brief list of administrators, and data access on the web application is limited based on user names.
If anyone is stuck with this and needs help, let me know!
My company has a MediaWiki setup which we are looking to make [partially] client accessible. Ideally each client would be able to see only their own page. Our wiki requires the user to be logged into view or edit, and we have the LDAP plugin (This one, specifically) so we can use our Active Directory credentials.
I see this question has come up before a few years ago, but I didn't see an question dealing with LDAP in particular. Can we manage a specific AD account if we give clients one on our domain for this purpose? Alternatively, is there a way to give clients a login directly into the wiki (sort of like logging locally into the computer, instead of the domain), that we could control the access rights of?
For reference: we are on MediaWiki version 1.19.1, PHP version 5.3.15, MySQL version 5.0.96-winx64, and the installation is running on Windows Server 2008 R2 x64 (IIS 7.5).
Thanks very much for the help!
You can use local accounts in addition to the LDAP accounts to log users in. You have to set $wgLDAPUseLocal to true in your LocalSettings.php. Basically, it adds another option to the domain drop down box on the login form that says "local". Users that want to log in with a local wiki account use that. I would also disable account creation on the wiki and create accounts manually for your clients.
Regardless of whether you use local accounts or AD accounts, for page-level access control, you would have to use one of these extensions. Extension:AccessControl seems to be a popular one.
Our users' web passwords/usernames/firstname/lastname/etc are in the dbo.contacts table in our CRM. This is great for CRM and our CRM compatible apps, but I would love to query these accounts with software that can only query LDAP.
Is it possible to tell openldap, "Hey, create logins using this table*" and to update this information periodically as obviously information changes over time? My scripting-fu isn't very strong but I've worked with php and webservices and would just like to get ldap talking to this table so I can get serious with single-sign-on.
Thanks.
*This can be a live connection to the CRM db via odbc/ado, a csv file, or connection via webservices.
This has nothing to do with OpenLDAP. LDAP clients can use the add request to add entries, assuming the client's authorization state allows adding users under the base object chosen by client. There is a standalone modify client called ldapmodify. Please "LDAP: Mastering ldapmodify" for more information.
Be aware that the some versions of the openldap ldapmodify tool are broken in that it incorrectly allows values with trailing spaces (which is illegal). The directory server base 64 encodes these values, which is probably not what was intended.
I have various projects being built and tested periodically on a Hudson server, but I don't want every employee in the company to see published artifacts for every project.
Project-based matrix security seemed at first the key, but after many tests I find that granting overall read permissions is mandatory if you want users to be able to read anything in the hudson server.
So, in the end read permissions are binary: either you grant global read permission or you block everything, am I right?
Haven't it tested with the newest release, but I use the matrix setup. I gave Anonymous the overall read. This way they can see the login screen when they type {{http://servername:port/}} but does not give them access to the jobs. In the jobs themselves I configured the users that should actually see the job. Works like a charm.
UPDATE:
Meanwhile I found out that you can use authenticated instead of Anonymous. This enabled access to Hudson/Jenkins through the links in the Build failed messages. Now everyone gets the logon dialog and after signing in, they are right away at the job run of interest.
After trying to do something similar to you with Hudson's authorization settings, I came to the same conclusion you did.