Turn editing On button is showing in course page to authenticated users in Moodle.
I have tried editing authenticated users permissions but it is still there.
Seems like some permissions are overriding but i can't set it to default.
In the reports setting, capability block is showing following line:
moodle/course:update: Update course settings
I was struggling from 2 days with this issue, finally find solution. This might help someone in future.
Actually the scenario is that Every guest and loged in user is having same rights as "Authenticated user" in moodle. (version 3.0)
issue was that authenticated user is having right to edit course. There was no permission assigned to authenticated user except following:
block/community:myaddinstance
block/course_list:myaddinstance
block/course_overview:myaddinstance
Add a new random glossary entry block to Dashboard
block/html:myaddinstance
block/navigation:myaddinstance
block/news_items:myaddinstance
moodle/portfolio:export
moodle/user:manageownfiles
report/courseoverview:view
moodle/badges:earnbadge
moodle/calendar:manageownentries
moodle/comment:post
moodle/comment:view
moodle/course:sectionvisibility
moodle/course:viewhiddensections
moodle/rating:viewall
moodle/rating:viewany
block/online_users:viewlist
block/site_main_menu:addinstance
moodle/block:view
mod/folder:view
mod/imscp:view
mod/page:view
I turned the following permission to Prohibit and now turn editing on button is not showing to Authenticated Users. Still don't know which of the following worked for this issue. but any one struggling with this issue can overview complete list of permissions from this post.
moodle/comment:post
moodle/comment:view
moodle/course:sectionvisibility
moodle/course:viewhiddensections
moodle/rating:viewall
moodle/rating:viewany
block/online_users:viewlist
block/site_main_menu:addinstance
Related
I know there's an earlier question with this subject here, but the OP never reported if the one answer resolved the issue. And since
Internal Server Error
is about as user-unfriendly as you can get, I would love to change this to something that feels more like "a message" than "an anvil dropped on your foot".
I have found one other SO post that tangentially relates to this issue (about that disappearing "duplicate emails" switch), but the problem is indeed not about whether or not to allow duplicate emails (or how to revive hidden admin controls) but how a very ordinary issue is communicated to the user - well, like how Keycloak notifies the user when they try and register with an existing username.
We're currently using the Docker version of Keycloak 12.0.4 with some customisations (a custom BCrypt module, some logging changes) running in IBM Cloud, using a Postgresql DB. We also added a custom theme & internationalisation. The same error occurs also when using the default Keycloak theme, though.
Here are our Login settings:
It turned out to be a configuration issue, but so deeply hidden that even the Keycloak developer who looked into the ticket I created had glossed over it.
The perpetrator was in menu Configure > Authentication > tab: Flows > choose dropdown: Registration > Profile validation radio button [o REQUIRED | o DISABLED]
This was set to disabled, which in effect prevents the duplicate email check in the registration form that the Realm settings > tab: Login form suggest are active. But then, of course, the database won't like that, with above-mentioned result.
This combination of settings should at least issue a warning, of course. I hope this will be corrected.
In Keycloak, by default, users are able to change their first and last name in the account manager page. However, is it possible to disable this behavior?
Removing both fields in the theme results in those values not being sent and the form failing, and a hand-crafted POST request would defeat this method anyway.
I came across a similar problem and after reading this SO post, came to know that although you can disable/hide fields in ftl, you cannot disable form validation
For e.g I hid firstname field , but still cannot submit. Same was the result with disable as well:
I am not aware about disabling a particular field in some other way. However there is a workaround in which you can disable the entire account modification flow (Password can still be changed by Forgot Password option).
Bu default, account modification is enabled, but you can disable it for a particular realm by going to Realms -> Clients -> Account.
The result of this will be, the account page will be inaccessible:
You can remove the client role 'manage_account' for client 'account'.
In Keycloak, by default, users are able to change their first and last
name in the account manager page. Is it possible to disable this
behavior?
That can be done out-of-the-box (since Keycloak 14) by using the user profile functionality. First, the preview feature declarative-user-profile has to be enabled. For that start the server with:
--features=declarative-user-profile.
for the Quarkus version, or with
-Dkeycloak.profile.feature.declarative_user_profile=enabled
for the Wildfly version.
Bear in mind that:
Declarative User Profile is Technology Preview and is not fully
supported.
After starting the server with the aforementioned option, go to the Keycloak Admin Console and:
Go to the according Realm;
Go to the tab General;
Set User Profile enabled to ON
A new tab named User Profile (top right) will show up; click on it, and a set of configurable attributes will be shown.
Click on firstName, and then go to Permissions
In that section the permissions can be changed, accordingly. For example, if one sets Can user edit? to OFF, then when the user tries to change the firstName field in the account UI, that UI throws the following warning message:
The field First name is read only.
The same configuration can also be applied to the lastName attribute.
For the new Keycloak UI the workflow is exactly the same as the one I have just described. More information about the feature can be found in the official keycloak documentation (link)
You can use readonly property to disable email you can just change the following line:
<input type="text" class="form-control" id="email" name="email" readonly autofocus value="${(account.email!'')}"/>
I don't known why it occurred which it was public to everyone last week.But today when I test again,it showed me a lock and said only me in Facebook on the right of the post.
I have searched this issue in stackoverflow,found some method to change it manually. But it did not worked.
someone said to change the privacy setting:Apps > Your_APP_NAME > Settings > Permissions > Default Activity Privacy.
someone said to change in the code to set the audience:
authButton.setDefaultAudience(SessionDefaultAudience.EVERYONE);
Thanks for any tips.
I think I have resolved this problem.
Don't use LogginButton to log in when you want to post.
To use this code below to log in:
session = new Session(this);
Session.setActiveSession(session);
session.openForPublish(new Session.OpenRequest(this)
.setCallback(statusCallback)
.setLoginBehavior(SessionLoginBehavior.SUPPRESS_SSO)
.setPermissions(Arrays.asList("publish_actions")));
Note: It is openForPublish not openForRead.And then set the permission.
I'm using devise/omniauth to do facebook authentication and works great. However, I would like to add a flow where an existing (non-facebook) user has ability to connect his account with facebook. This would require different facebook permissions. so i can't seem to find two things
how to use devise/omniauth to request facebook connect without logging out current user
request different extended permissions from user (different from those specified in the devise configuration file)
any ideas? thanks
Answer to 1 is pretty easy: just add a if path into the omniauth_callbacks_controller::process_callback method like this
# If a user is signed in then he is trying to link a new account
if user_signed_in?
if authentication.persisted? # This was a linking operation so send back the user to the account edit page
flash[:success] = I18n.t "controllers.omniauth_callbacks.process_callback.success.link_account",
:provider => registration_hash[:provider].capitalize,
:account => registration_hash[:email]
else
flash[:error] = I18n.t "controllers.omniauth_callbacks.process_callback.error.link_account",
:provider => registration_hash[:provider].capitalize,
:account => registration_hash[:email],
:errors =>authentication.errors
end
redirect_to edit_user_account_path(current_user)
This is what I do in my application and it works fine.
Regarding question 2 I do not know how to support 2 different facebook authentication configurations however I have hard time seeing how that is useful to users since they need a consistent experience across both path: "sign in using facebook" and "link your account to facebook".
(If you still want to pursue this path one idea I would explore is to create a new facebook application with its independent keys and configuration...)
Hope this help.
One simple way to implement multi-tier permissions is to use Facebook Javascript SDK(in addition to omniauth, if you want). You can simply specify different "scope" parameter, which specifies permissions required, at each call you want. What I'm doing is making omniauth provide a basic set of permissions, then, after the user has connected through omniauth(and thus stored their data in our DB), if further permissions are needed, we show them JS-based buttons which provide expanded sets of permissions. If you want to check what particular permissions a user has granted to you, you can simply use me/permissions API call.
I am adding Facebook login to my existing asp.net application. I have added a Facebook login button to my login screen. Now, I click Facebook's login button and in IE 9 it throws client-side exception in all.js on Line 22: if(a.params)b.fbCallID=a.id;
Even after that exception I see the Facebook login screen and can log in, and in the main browser window I get the auth.login event, so I can live with that.
But, if I am already logged in to Facebook, I come to the page and click Facebook login button, I briefly see the empty popup window, then I get teh same client-side exception, and then I get no event in the main browser window, so I don't know if the user logged in so I can't redirect them to another page.
I tried the channelUrl trick but it didn't help.
Any suggestions what's going on?
I found this hack that fixed the issue for me; add this line right after you call FB.init():
// Hack to fix http://bugs.developers.facebook.net/show_bug.cgi?id=20168 for IE7/8/9
FB.UIServer.setLoadedNode = function (a, b) {
FB.UIServer._loadedNodes[a.id] = b;
};
The reason it is happening (from the websites and documents I have read, and believe me, I've read a LOT) is that IE refuses cross-site javascript, and it sees the all.js as crossing the sandbox border. A good discussion can be found here.
Some people say that adding the channel.html file works, but we have tried all flavors of that, and have not had any success. (Remember that the http or https must match the page sending the request.)
Microsoft makes reference to this same issue and their advice is to add the site to trusted sites (that doesn't help). Old advice (from last year) is to add CP="HONK" as your compact privacy policy, but I think that bug was fixed, and it was cookie-related.
What seems to be happening to us is that the login actually continues, and the callback gets called properly, but the main thread that should complete outside of the login call stops executing (because of the error). So, any functions outside the login fail to execute after the login call.
If anyone has a way to get IE to not throw the exception or to create a workaround for this issue, I am desperate to have it. Any info needed I will be happy to provide, but a sample is here:
enter code here
code before login here...
FB.login(function(response){
callback stuff here... This part fires.
});
main thread stuff here... This fails because of permission denied error.