An annotation platform designed for teaching and learning in the humanities, and with aspirations to more general use.
There are two servers required to run this application. This one, and the MIT Annotation Data Store.
You MUST get the Annotation server running to be able to create or view annotations.
Annotation Studio uses PostgreSQL
The MIT Annotation Data Store requires Node.js (0.10.21), NPM (1.3.11) and MongoDB
Set up Rails (if you haven't yet, try: [thoughtbot's Laptop repo] (https://github.com/thoughtbot/laptop))
annotation-studio```cd annotation-studio./bin/setupwhich will:
./tmp/annotation_data_storeAfter setting up the app, run:
bundle exec foreman start -f Procfile.devto spin up development dependencies. You can exist the development daemons by hitting ctrl-c, per normal unix semantics.
If you would like to run the application on Heroku (recommended), do the following
heroku apps:create $APPNAMEheroku addons:add heroku-postgresql
application.yml into environment variables and
communicate them to Heroku
rake figaro:heroku[$APPNAME]This app uses the apartment gem to allow multiple domains to be hosted in a single instance.
To create a new tenant:
app/assets/images/
app/views/saml/ (use an existing tenant metadata file as a guide)app/views/shared/ (use an existing tenant brand file as a guide)config/domain_specific/config.yml (use an existing tenant entry as a guide)RAILS_ENV=production bundle exec rake assets:precompile && git add public/assets/ && git commit -m "Add precompiled assets"cove-studio app in Heroku under Settings > Domainscopy_vetted_documents rake task through the Heroku CLI:
heroku run rake copy_vetted_documents[source-db,destination-db] -a cove-studiosource-db value is usually cove-studioApartment::Tenant.switch!(‘name-of-tenant-db)User.find(1).set_roles = [“admin”])Role.allstudent, teacher, and adminYou will need to integrate COVE with the new tenant's SAML system. There are certain requirements for the settings:
There will still be issues, because every school's system is just a little bit different.
A common issue is that the school forgets to disable encryptAssertions - when there are login issues, always double-check for this first. A typical sign of encryptAssertions being set incorrectly is when the user seems to sign in successfully, but is kicked back to the homepage. If you watch the server logs, you'll see Authentication failure! invalid_ticket: OneLogin::RubySaml::ValidationError, An EncryptedAssertion found and no SP private key found on the settings to decrypt it., confirming that the setting is incorrect on the tenant's end.
If the school uses Microsoft Azure, releasing the correct attributes in a way that COVE understands is a bit counterintuitive. For each attribute, the name field should be the "urn:oid" identifier from above.
The setup that Azure requires is:
| Name | Source Attribute |
|---|---|
| urn:oid:2.5.4.42 | user.givenname |
| urn:oid:2.5.4.4 | user.surname |
| urn:oid:0.9.2342.19200300.100.1.3 | user.mail |
The "namespace" field on the names should be kept empty (there may be something there by default).
As of this writing, two COVE tenants use OpenAthens.
OpenAthens requires a slightly different metadata file. In each of the two cases, the tenant had to do some special setup on their side.
Take a look at doc/openathens_example_metadata.xml for an example - this tenant reached out to OpenAthens support after lots of back-and-forth with us, and they provided the tenant with this working metadata file.
Especially note the wantsAssertionsSigned="false". Turning off encrypted assertions tends to be a pain point for new tenants, and OpenAthens makes it especially challenging.
For future reference, the Mongo query for updating annotations when a tenant changes their name/email is available at doc/torontomu_annotations_mongo_query.
http://support.annotationstudio.org
Thanks to: