From Chromes developer tools, what is the full path of the 404’d object. For example, is it https://xyz.de/ltitools/engage-ui.js, or https://xyz.de/engage-ui.js, or https://xyz.de/engage/engage-ui.js?
If you are logged into the engage server and paste that path directly into your browser, does it still return a 404 for the file, or does it find it?
Hi Sven and mostolog,
I suspect this is related to the roles that the user has in relation to the URL permissions defined in mh_default_org.xml
First, when logged in as an LTI user, access /info/me.json to see the effective roles that the user has.
You could try this change in mh_default_org.xml:
<!-- Enable access to the LTI tools -->
<sec:intercept-url pattern="/ltitools/**" access="ROLE_OAUTH_USER, ROLE_USER" />
but it’s possible that the player is somehow not being loaded correctly. Can you provide the full path that the user is being redirected to after LTI authentication, the player URL and the full paths of the jss and CSS files that are getting 404s?
For Sakai integration, you can also enable the Sakai user provider by copying org.opencastproject.userdirectory.sakai-default.cfg.sample to org.opencastproject.userdirectory.sakai-yourname.cfg and configuring it for your Sakai instance. This will give logged-in users a set of roles based on their Sakai site membership.
Regards
Stephen
---
Stephen Marquard, Learning Technologies Co-ordinator,
Centre for Innovation in Learning and Teaching (CILT)
University of Cape Town
http://www.cilt.uct.ac.za
stephen....@uct.ac.za
Phone: +27-21-650-5037 Cell: +27-83-500-5290
--
You received this message because you are subscribed to the Google Groups "Opencast Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
users+un...@opencast.org.
I think you need to add
prop.lti.player.url=/engage/theodul/ui/core.html?id=
to org.opencastproject.organization-mh_default_org.cfg
https://groups.google.com/a/opencast.org/forum/#!msg/announcements/fvLp0It-K1c/EjSy4a0JBQAJ
Regards
Stephen
---
Stephen Marquard, Learning Technologies Co-ordinator,
Centre for Innovation in Learning and Teaching (CILT)
University of Cape Town
http://www.cilt.uct.ac.za
stephen....@uct.ac.za
Phone: +27-21-650-5037 Cell: +27-83-500-5290
From: mostolog [mailto:most...@gmail.com]
Sent: 24 April 2017 04:28 PM
To: Opencast Users <us...@opencast.org>
--
You received this message because you are subscribed to the Google Groups "Opencast Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to
users+un...@opencast.org.
I suspect this is related to the roles that the user has in relation to the URL permissions defined in mh_default_org.xml
First, when logged in as an LTI user, access /info/me.json to see the effective roles that the user has.
{"org":{"anonymousRole":"ROLE_ANONYMOUS","name":"My Opencast","adminRole":"ROLE_ADMIN","id":"mh_default_org","properties":...
As I'm testing from browser, it won't probably behave the same way as LTI, but it could help.
but it’s possible that the player is somehow not being loaded correctly.
Can you provide the full path that the user is being redirected to after LTI authentication, the player URL and the full paths of the jss and CSS files that are getting 404s?
For Sakai integration, you can also enable the Sakai user provider by copying org.opencastproject.userdirectory.sakai-default.cfg.sample to org.opencastproject.userdirectory.sakai-yourname.cfg and configuring it for your Sakai instance. This will give logged-in users a set of roles based on their Sakai site membership.
Hi,
Can you send a screenshot of what you're filling in on https://lti.tools/test/tc.php? You could also try testing from one of the Sakai QA servers (http://nightly2.sakaiproject.org/)
The launch URL for LTI is a POST to /lti
So this URL won't work as the LTI endpoint:
The tool=... part is part of the LTI launch parameters, and is where the user is redirected to as the response from the POST to /lti
You should be able to specify
tool=/engage/ui/index.html
and see the same Media Module that you can access via the Admin UI.
The /info/me.json that you've posted looks like it's after you've logged in to Opencast as admin. You should able to start an LTI session (without having logged in to Opencast previously), then open another browser tab and open direct http://some.server/info/me.json and you should see the username provided by LTI and a few roles.
Regards
Stephen
Can you send a screenshot of what you're filling in on https://lti.tools/test/tc.php?
and see the same Media Module that you can access via the Admin UI.
The /info/me.json that you've posted looks like it's after you've logged in to Opencast as admin. You should able to start an LTI session (without having logged in to Opencast previously), then open another browser tab and open direct http://some.server/info/me.json and you should see the username provided by LTI and a few roles.
BTW: I'm getting a 404 on http://redacted:8080/engage/ui/language/es-ES.json
Hi Mostolog,
Please refer to our project in Crowdin: https://crowdin.com/project/opencast-matterhorn
We do not commit the translation files directly, but we use crowdin to get the translation done, then the release manager(s) merge these changes into the Opencast code.
Regards
Rubén
--
You received this message because you are subscribed to the Google Groups "Opencast Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to users+un...@opencast.org.
Crowdin seems to require register and joining translator team..
Here's the translation.
{ "series":"Series", "episodes":"Episodios", "sort":"Ordenar", "recording_date_new":"Fecha de grabación (Más reciente)", "recording_date_old":"Fecha de grabación (Más antigua)", "publishing_date_new":"Fecha de publicación (Más reciente)", "publishing_date_old":"Fecha de publicación (Más antigua)", "title_a_z":"Título (A-Z)", "title_z_a":"Título (Z-A)", "author_a_z":"Autor (A-Z)", "author_z_a":"Autor (Z-A)", "contributor_a_z":"Colaborador (A-Z)", "contributor_z_a":"Colaborador (Z-A)", "publisher_a_z":"Publisher (A-Z)", "publisher_z_a":"Publisher (Z-A)", "language":"Idioma", "license":"Licencia", "subject":"Asunto", "description":"Descripción", "search":"Buscar", "no_episodes":"No hay episodios disponibles.", "no_series":"No hay series disponibles.", "prev":"Anterior", "next":"Siguiente", "first":"Primero", "last":"Último", "login_title":"Iniciar sesión con una cuenta de Opencast.", "login_request":"Por favor, introduzca usuario y clave.", "username":"Usuario", "password":"Clave", "remember_me":"Recordarme.", "sthWentWrong":"Algo ha ido mal. Por favor, inténtelo de nuevo.", "loading":"Cargando ...", "no_data":"No hay datos disponibles.", "login_success":"Acceso correcto.", "login_failed":"Acceso erróneo.", "not_logged_in":"Sesión no iniciada." }
Hi,
This presentation may be helpful in describing the interaction between users, roles, groups, permissions and providers:
https://www.slideshare.net/smarquard/opencast-valencia-2017-users-groups-roles-acls-and-providers
To configure the Sakai UserDirectoryProvider for Opencast, you need to:
1. Rename etc/org.opencastproject.userdirectory.sakai-default.cfg.sample to org.opencastproject.userdirectory.sakai-default.cfg
2. Configure the URL, user and password fields in the cfg file.
3. Check the logs to make sure that the provider is resolving user information correctly. You can increase the log level if you wish to DEBUG for this class by adding to etc/org.ops4j.pax.logging.cfg:
log4j.logger.org.opencastproject.userdirectory.sakai=DEBUG
Changes to the logging cfg file will reflect immediately, i.e. you do not need to restart Opencast.
4. To make sure your LTI users and Opencast/Sakai users are the same, be sure to configure your LTI as a trusted source, for example:
<!-- ####################### -->
<!-- # OAuth (LTI) Support # -->
<!-- ####################### -->
<!-- This is required for LTI. If you plan to use LTI, uncomment this and set
custom values for consumerkey and consumersecret: -->
<bean name="oAuthConsumerDetailsService" class="org.opencastproject.kernel.security.OAuthSingleConsumerDetailsService">
<constructor-arg index="0" ref="userDetailsService" />
<constructor-arg index="1" value="consumerkey" />
<constructor-arg index="2" value="SOMEPASSWORD" />
<constructor-arg index="3" value="constructorName" />
</bean>
<bean name="oauthProtectedResourceFilter" class="org.opencastproject.kernel.security.LtiProcessingFilter">
<property name="consumerDetailsService" ref="oAuthConsumerDetailsService" />
<property name="tokenServices">
<bean class="org.springframework.security.oauth.provider.token.InMemoryProviderTokenServices" />
</property>
<property name="nonceServices">
<bean class="org.springframework.security.oauth.provider.nonce.InMemoryNonceServices" />
</property>
<property name="authHandler">
<bean class="org.opencastproject.kernel.security.LtiLaunchAuthenticationHandler">
<constructor-arg index="0" ref="userDetailsService" />
<constructor-arg index="1" ref="securityService" />
<constructor-arg index="2">
<list>
<value>consumerkey</value>
</list>
</constructor-arg>
</bean>
</property>
</bean>
In the above example, the LTI specified by "consumerkey" is trusted to provide users that are the same as Opencast internal users. If an LTI consumer is not trusted, the LTI users are namespaced in Opencast with a prefix, and they won't match up with internal Opencast users.
The User Providers are consulted for any type of user authentication or login, i.e. via LTI, direct login to Opencast, LDAP, or SSO like CAS, Shibboleth.
The effect of the Sakai UserDirectoryProvider is to give Opencast users who also exist in Sakai an additional set of roles based on their Sakai site membership.
The Sakai group provider also gives users who exist in Sakai group membership of ROLE_GROUP_SAKAI and you can use this group to give Sakai users additional roles (for example to allow them to use the Admin UI).
The last piece of the puzzle is that if you want LTI users to be able to do tasks like schedule recordings or update the details of scheduled recordings (via an embedded LTI UI rather than the Admin UI), you need more capable LTI tools (these are pure HTML/JS - no java code changes). Here is UCT's version:
Allowing LTI users to schedule and update scheduled events requires them to have a few more permissions so that they can use some of the /admin-ng/ endpoints that are required. In our Opencast, we have enabled this by granting these roles to ROLE_GROUP_SAKAI:
It would be great to have some more documentation about this, so that would be a valuable contribution.
Regards
Stephen
This presentation may be helpful in describing the interaction between users, roles, groups, permissions and providers:
https://www.slideshare.net/smarquard/opencast-valencia-2017-users-groups-roles-acls-and-providers
1. Rename etc/org.opencastproject.userdirectory.sakai-default.cfg.sample to org.opencastproject.userdirectory.sakai-default.cfg
2. Configure the URL, user and password fields in the cfg file.
3. Check the logs to make sure that the provider is resolving user information correctly. You can increase the log level if you wish to DEBUG for this class by adding to etc/org.ops4j.pax.logging.cfg:
log4j.logger.org.opencastproject.userdirectory.sakai=DEBUG
In the above example, the LTI specified by "consumerkey" is trusted to provide users that are the same as Opencast internal users. If an LTI consumer is not trusted, the LTI users are namespaced in Opencast with a prefix, and they won't match up with internal Opencast users.
The User Providers are consulted for any type of user authentication or login, i.e. via LTI, direct login to Opencast, LDAP, or SSO like CAS, Shibboleth.
The effect of the Sakai UserDirectoryProvider is to give Opencast users who also exist in Sakai an additional set of roles based on their Sakai site membership.
The Sakai group provider also gives users who exist in Sakai group membership of ROLE_GROUP_SAKAI and you can use this group to give Sakai users additional roles (for example to allow them to use the Admin UI).
The last piece of the puzzle is that if you want LTI users to be able to do tasks like schedule recordings or update the details of scheduled recordings (via an embedded LTI UI rather than the Admin UI), you need more capable LTI tools (these are pure HTML/JS - no java code changes). Here is UCT's version:
Allowing LTI users to schedule and update scheduled events requires them to have a few more permissions so that they can use some of the /admin-ng/ endpoints that are required. In our Opencast, we have enabled this by granting these roles to ROLE_GROUP_SAKAI:
It would be great to have some more documentation about this, so that would be a valuable contribution.
OK, it seems that we neglected to add the sakai provider to:
It should be listed there just under
<bundle start-level="82">mvn:org.opencastproject/matterhorn-userdirectory-ldap/${project.version}</bundle>
<bundle start-level="82">mvn:org.opencastproject/matterhorn-userdirectory-sakai/${project.version}</bundle>
...
Hi,
I'm assuming that you see ROLE_GROUP_SAKAI as one of the roles in the /info/me.json output for an Opencast user who exists in Sakai?
If that's the case, you should be seeing
2017-04-28 12:41:08,118 | WARN | qtp1922345447-9983 | (JpaGroupRoleProvider:239) - Group ROLE_GROUP_SAKAI not found
in the logs when a user logs in and gets resolved by the Sakai provider.
All you have to do now is create a group in the Admin UI with the name "Sakai" (the role name will be set to ROLE_GROUP_SAKAI). We should possibly add some code to make that group get created automatically if it doesn't exist.
In the Admin UI, you won't see a list of Sakai users in the ROLE_GROUP_SAKAI membership however (in general we didn't want every single Sakai user to show up in Opencast for performance reasons).
If you look at an individual user whoever who is resolved by the Sakai provider, you'll see ROLE_GROUP_SAKAI show up under Effective Roles, e.g.:
All you have to do now is create a group in the Admin UI with the name "Sakai" (the role name will be set to ROLE_GROUP_SAKAI). We should possibly add some code to make that group get created automatically if it doesn't exist.
In the Admin UI, you won't see a list of Sakai users in the ROLE_GROUP_SAKAI membership however (in general we didn't want every single Sakai user to show up in Opencast for performance reasons).
In general, you have to associate a Series in Opencast with one or more Sakai sites (Sakai Site ID + Sakai role = Opencast role) when the series is created. Events will inherit the Series ACL when they are created.
For documentation, the user providers should probably be documented under security, as they don't depend on LTI specifically.