I've exhausted my search on moodles site and the web-at-large.
I have a need to grant an individual (not a registered/regular user) temporary access to take a course/quiz, capture results and archive actions.
I want to manually enter said user into moodle and assign them a "guest" role so that I can then enrol them into a course and accomplish said goal.
The problem is, when I exercise this, the "guest" can view categories, courses and some other items within the site. I do not want the guest to be able to see ANYTHING but the assigned course (and their grade)...I want to "lock-it-down".
I have been through every permission to the extent of "Prohibiting" everything, however, the guest role is still able to select some items and "peak" into other categories/courses.
Moreover, I don't want them to see the same menu items either...such as Dashboard
If you can point me in the right direction or solve this problem, I will be forever grateful.
Thank you,
Mark
Manually entering said user will make her registered whatsoever, nevermind assigning her a guest role, which is, as I understand, heavily modified by you at this point (best practice here is to create your own copies of role instead of modifying existing ones).
The solution will require code modifications, since role capabilities are not covering everything. However, you may prohibit user to peek into any course(not category) by prohibiting self-enrolments, if it suits your strategy.
Related
I've gone through several tutorials on Flutter and I find that they cover basics just fine but there are some nagging aspects of good design and good architecture that are consistently missing. I'm writing my first actual (not toy) application in Flutter and find myself running into these missing points.
Global data. Once a person installs the application and tries to use it, I ask them to log in / create an account, since this is an application specifically for managing groups of people. I'm using Firebase on the back end, and the package to do authentication winds up returning Future<FirebaseUser> from everything. So, yes, when it comes to building a Widget that uses the user's data, I can use a FutureBuilder. That said, it seems weird to have to keep typing boilerplate FutureBuilder code to dereference the user every place I want to use the user's ID to look up their data (what groups are they part of, what actions do they have pending, etc.). I really feel like there ought to be a way to invoke the future, get the actual user object, and then store it somewhere so that anything that wants a user ID for a query can just go get it. What's the right solution? I can't believe I'm the only person who has this problem.
Updatable data. I've got a page where I list the groups the current user is a member of. The user, though, can create a new group, join an existing group, or leave a group. When they do that, I need to redraw the page. The list of groups comes from running a Firebase query, so performing an action (join, leave, etc.) should signal the app to redraw the page, which will have the side effect of re-running the query. Conceivably, one might make the page dependent (how?) on the query results and have it redraw whenever they update, and instead have some widget somewhere that keeps track of the query. There's another answer here that hints that this might be the right way to go, but that's really concerned with relatively invariant data (locale doesn't change all that often for a single user). So, again, I can't believe I'm the only one who does this sort of thing. What's the best practice in this case?
We are using perforce in my company and heavily rely on it. I need some suggestion for the following scenario:
Our Depot structure is something like this:
//depot
/product1
/component1
/component2
.
.
/componentN
/*.java
/*.xml
/product2
/component1
/component2
.
.
/componentN
/*.java
/*.xml
Every product has multiple components and every component consist of java or xml or some other program file. Every component has a manager/owner associated with it.
Right now, we have blocked the write permissions for every user and only when it is approved by the manager/owner after code review, we open the write permission for that user for any file/folder to check in. This process becomes a little untidy because the manager/developer have to wait for perforce admin to allow permissions (update protections table of perforce). Also, we give them a window of only 24 hrs to check in (due to agile, which i dont understand much :)), after which we are supposed to block the write access again for that user.
What I am looking for is a mechanism where perforce admins can delegate this responsibility to respective managers/owners without giving them super user or admin access and which automatically disables the write permission after 24 hrs.
Any suggestions ?
Thanks in advance.
There's nothing to do this out of the box, per se.
The closest thing I can think of is if the mainline version of these components were permissioned by a group with an owner. The owner of the group is allowed to add and remove members from the group, thus delegating the permissioning to the "gatekeeper" rather than the admins, themselves.
Let me know if you require further clarification about this.
One common solution is to build a simple tool which reads and writes the protections table, the group memberships, etc., to implement the policies that you desire.
The protections and groups data are not complex in format, and you can easily write a little bit of text-processing code that writes and re-writes these specs according to your needs.
Then install your tool on the server machine in a secure fashion, granting the tool the rights to update the protections table, and have your component administrators use the tool to manage the permissions.
For example, I've seen this done by writing a small web application, in Java or Perl for example, installing that on a web server on a secure machine, and letting the component admins operate that tool through a web interface.
All your tool has to provide is (a) a simple login/logout mechanism for your component admins (the web server may already do this for you), (b) a command that takes a user name and a folder name and grants permission, and (c) a command (or a timer) that removes that permissions subsequently.
I am working on an application that will allow the user to purchase content from the app store
https://developer.apple.com/library/mac/#documentation/NetworkingInternet/Conceptual/StoreKitGuide/Introduction/Introduction.html#//apple_ref/doc/uid/TP40008267-CH1-SW1
These products require a "ProductID" that ties them to whatever is in the appstore.
I will need to store these IDs somewhere in the application so I know what to send the server when the purchase button is clicked.
I wish to expose these ID's and allow non-programmers to enter any ID they want in both our side and the server side, and not have to call on a programmer to go into the code and change some enum.
I figured a config file would not be very secure, for in the end it's just a text file that a user could potentially view after purchasing the app. May not be a huge problem if a user saw the ID, but I don't like the idea of anybody seeing the innards that go through a payment process
Assuming im making sense here, whats a good way to expose these IDs but still keep them secure so users may not find them?
Also curious, how secure is something like an enum in c++? Can people break the .exe down and see the code and its values?
For your final question, yes and no. If they have access to the debugging information (a PDB in Microsoft land) then yes. But armed with just an exe and disassembler, you will see only the constant values that are assigned to the enum members.
So as to avoid overwhelming the infrastructure in a web application instance, what would be the methods of implementing a feature roll out to a controlled group of your user-base?
It depends on the situation. You can't really redirect them to another site using another database if the users are expecting to work with real data and the real site.
I would introduce a flag on your users in your user-table, let's say isBetaUser (bool). Then you can just show these new features for users that got this flag set to True. You could also let them check this flag off using a checkbox through some settings page, if they don't like the idea of trying out new features that is.
Partition your users into groups. Randomly. Demographically. Somehow.
Pick one or more groups for a pilot.
Fix your web site to have both versions of your app running. Maybe use virtual hosting or a different path or something.
One database. Two applications. Data doesn't move. Only the presentation changes.
At first, all users are in the old version. Workload has not changed.
Move a group of users so that their default URL's or links or menus or whatever are references to the new application.
Same workload. Same database. Same number of users. Two applications.
Move another group of users to the new application.
Same workload. Same database. Same number of users. Two applications.
Eventually, after all users are moved, you can delete the old application.
I'm using Catalyst with Catalyst::Plugin::Authentication and
Catalyst::Plugin::Authorization::Roles and am wondering if there is a better
approach to adding an attribute to a model that I'm not seeing.
Each user is permitted to access one or more companies, but there is
always one primary (current) company at a time. The permitted list is
stored in the database, and database access is primarily through DBIC.
My first inclination is to say that it's the user that has a current
company, and thus put it as part of the user model: give the user
package a "sub company { … }" to get/set the user's current company. The
database check is fairly easy; just use "$self->search_related" (a DBIC
method, inherited by the user model).
The problems I run in to are:
The current company needs to persist between requests, but I'd rather
not store it to the database (it should only persist for this
session). The natural place is the session…
There is a role, akin to Unix's root, that allows you to act as
any company, ignoring the list in the database. Checking this role
can be done through the database, but everywhere else in the app uses
$c->assert_user_role and friends.
I've heard its best to keep the models as Catalyst-independent as
possible. It also seems pretty weird to have a model manipulating
$c->session.
Of course, I could move those checks to the controllers, and have the
model accept whatever the controller sends, but that's violating DRY
pretty heavily, and just begging for a security issue if I forget one of
the checks somewhere.
Any suggestions? Or do I just shrug and go ahead and do it in the model?
Thanks, and apologies for the title, I couldn't come up with a good one.
The key is to create an instance of the model class for each request, and then pass in the parts of the request you need. In this case, you probably want to pass in a base resultset. Your model will make all the database calls via $self->resultset->..., and it will "just work" for the current user. (If the current user is root, then you just pass in $schema->resultset("Foo"). If the current user is someone else, then pass in $schema->resultset("Foo")->stuff_that_can_be_seen_by($c->user). Your model then no longer cares.)
I have some slides about this, but they are very outdated:
http://www.jrock.us/doqueue-grr/slide95c.html#end
(See the stuff immediately before and after, also.)
Note that restricted resultsets and web ACLs are orthogonal. You want to make the model as tight as possible (so that your app can't accidentally do something you don't want it to, even if the code says to), but various web-only details will still need to be encoded in ACLs. ("You are not allowed to view this page." is different from "You can only delete your own objects, not everyone's". The ACL handles the first case, the restricted resultset handles the second. Even if you write $rs->delete, since the resultset is restricted, you didn't delete everything in the database. You only deleted the things that you have permission to delete. Convenient!)