2013-01-22 01:16:29 +08:00
|
|
|
# What goes in this file:
|
|
|
|
|
# * local canvas configuration (db, ymls, overrides, etc.)
|
|
|
|
|
# * generated/cached stuff (docs, css, js, uploads, etc.)
|
|
|
|
|
#
|
|
|
|
|
# What does NOT go in this file
|
|
|
|
|
# * editor-related stuff
|
|
|
|
|
# * random scripts only used by you
|
|
|
|
|
# * env-specific stuff (e.g. .DS_Store)
|
|
|
|
|
# * pretty much any dotfile not already covered (e.g. .rvmrc)
|
|
|
|
|
#
|
|
|
|
|
# That's what .git/info/exclude and core.excludesfile are for :)
|
2014-02-01 07:52:04 +08:00
|
|
|
.bundle/
|
2016-11-23 03:43:39 +08:00
|
|
|
.env
|
2021-04-06 01:50:53 +08:00
|
|
|
.mutagen
|
2024-01-12 01:55:13 +08:00
|
|
|
.swc
|
2024-05-06 23:10:23 +08:00
|
|
|
.idea/
|
2013-01-22 01:16:29 +08:00
|
|
|
/.yardoc/
|
2017-01-19 05:12:06 +08:00
|
|
|
/.ruby-version
|
2013-03-20 00:58:55 +08:00
|
|
|
/app/views/info/styleguide.html.erb
|
2013-01-22 01:16:29 +08:00
|
|
|
/config/*.yml
|
2023-07-08 02:27:45 +08:00
|
|
|
/config/*.yml.cached
|
InstID tokens, part 1: generation
fixes INTEROP-6913, INTEROP-6892, INTEROP-6893, INTEROP-6920
flag = none
This commit introduces the InstID token, a signed and encrypted JWT (aka
JWE) that will soon be usable for Canvas API access (that's "part 2").
If the InstID class is configured with a private signing key and public
encryption key, it will be able to produce encrypted JWTs and validate
and deserialize decrypted JWTs. If it is configured with only a public
signing key, it cannot produce tokens but it can still validate and
deserialize decrypted ones. Therefore this class can be used by the
identity provider (currently Canvas) to produce tokens, but also by any
services that want to use InstID tokens for authentication.
test plan:
1) generate two RSA keypairs. one way to generate a keypair is from a
rails console:
> keypair = Canvas::Security::RSAKeyPair.new
> puts keypair.private_key.to_s
> puts keypair.public_key.to_s
2) choose which one is for signing and which is for encryption, then add
the private signing key and the public encryption key to your rails
credentials:
- run `bin/rails credentials:edit`
- add an entry like the following, and then save and close your
editor:
```
inst_id:
encryption_key: |
-----BEGIN PUBLIC KEY-----
MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBCgKCAQEAvY1EMlGm1daM87ejGuFX
<...snip...>
/wIDAQAB
-----END PUBLIC KEY-----
signing_key: |
-----BEGIN RSA PRIVATE KEY-----
MIIEpAIBAAKCAQEAnDwED/QOB0f0H6TOZqLmjaPqA7m8c40NDXkAa6u5cK8zCbk3
<...snip...>
QhjPgifBwTrzj21484CfiPfy5oe756Exerj8PIlRrE/hxWRSDwBIOg==
-----END RSA PRIVATE KEY-----
```
3) open a rails console and do:
> id = InstID.for_user('user-uuid')
> id.to_token # make sure this doesn't blow up
> token = id.to_unencrypted_token
> decoded_id = InstID.from_token(token)
> id.jwt_payload == decoded_id.jwt_payload # => true
TODO in followup commits:
- make canvas accept InstID tokens for auth
Change-Id: Ie550c17507c26f9944bd62a747a6a63161e8e770
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/268872
Reviewed-by: Ethan Vizitei <evizitei@instructure.com>
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Michael Ziwisky <mziwisky@instructure.com>
Product-Review: Michael Ziwisky <mziwisky@instructure.com>
2021-07-13 11:46:17 +08:00
|
|
|
/config/credentials.yml.enc
|
2023-04-10 23:09:02 +08:00
|
|
|
!/config/brakeman.yml
|
2023-07-28 01:05:47 +08:00
|
|
|
!/config/code_ownership.yml
|
2021-03-31 00:07:50 +08:00
|
|
|
!/config/credentials.test.yml
|
2021-12-01 03:56:30 +08:00
|
|
|
!/config/crystalball.yml
|
2013-01-22 01:16:29 +08:00
|
|
|
/config/environments/*-local.rb
|
2014-04-24 00:57:32 +08:00
|
|
|
/config/locales/generated/
|
2024-04-09 22:32:41 +08:00
|
|
|
/config/saml/*
|
2022-03-24 04:16:20 +08:00
|
|
|
/config/RAILS_VERSION
|
2015-03-10 03:34:59 +08:00
|
|
|
/coverage/
|
2016-07-12 03:03:13 +08:00
|
|
|
/coverage-js/
|
2013-01-22 01:16:29 +08:00
|
|
|
/db/schema.rb
|
|
|
|
|
/db/*sql
|
2019-10-22 05:51:15 +08:00
|
|
|
docker-compose.override.yml
|
2013-01-22 01:16:29 +08:00
|
|
|
/exports/
|
keep lockfiles in sync as part of `bundle` commands
closes AE-283
this eliminates script/sync_lockfiles.rb and integrates its
functionality directly into `bundle install`, `bundle check`, etc.
it also generalizes a few pieces so that the same approach is used
for all use cases:
* syncing versions between the main Gemfile and gems in gems/
* maintaining separate lockfiles for no plugins/including
private plugins
* maintaining separate lockfiles for multiple Rails versions
(crossed with the previous bullet)
The differences between them are just small variations on how strict
versions must match between lockfiles, and requiring pinning of
versions not in the default lockfile.
For full details, checks the docs on BundlerLockfileExtensions
This does change the strategy for filtering private plugin dependencies
out of the committed lockfile(s) - instead of filtering based on hash
of source, simply don't even include private plugin gems in the gemfile
when building the filtered lockfile (i.e. dynamic Gemfile, rather than
monkeypatching bundler to filter out -- semi-succesfully -- private
plugins from the Definition).
It also changes the "default" lockfile for Canvas that gets checked
in to be Gemfile.lock, so that other tools that are not
multi-lockfile aware can find it (such as rubocop, dependabot, and
others). This will be the lockfile corresponding to the current
default rails version for Canvas, and without private plugins.
Change-Id: I7ba398381974acbc4445f34fa3b788e8a07c5ce6
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/317888
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
Reviewed-by: Jacob Burroughs <jburroughs@instructure.com>
QA-Review: Cody Cutrer <cody@instructure.com>
Product-Review: Cody Cutrer <cody@instructure.com>
Build-Review: Cody Cutrer <cody@instructure.com>
2023-05-11 02:12:39 +08:00
|
|
|
/Gemfile.*.plugins.lock
|
2020-03-16 20:23:58 +08:00
|
|
|
/log/*
|
|
|
|
|
!/log/.keep
|
|
|
|
|
!/log/parallel-runtime-rspec.log
|
2015-12-05 01:51:12 +08:00
|
|
|
mkmf.log
|
2023-12-24 04:26:24 +08:00
|
|
|
node_modules
|
2015-12-05 01:51:12 +08:00
|
|
|
npm-debug.log
|
A new way of doing css/sass & New Canvas Theme Editor
what this does:
* Changes the way we generate css so we are able to generate custom
css for people that use the theme editor.
* Sets everything up so we can push all of our static assets
(js, fonts, css, images, etc) to s3 pre-deploy and serve them
from cloudfront. Yay! faster canvas for everyone!
* as part of that, this enables the rails asset pipeline just so we
can use it to put md5s in our urls. we don't use it for any of the
coffeescript/sass/sprockets transformer stuff.
* adds a new "Theme editor" functionality (only for people that have
have the use-new-styles feature flag turned on) where an admin for
an account can pick their own colors/images for all the users
at their account/school.
* when the user is done saving things in theme editor, it will,
in a delayed job, generate all the css with against the variables
that user specified and push it to s3 so it will be available to
anyone else that requests it. (the delayed job will shell
out to a node.js executable called `brandable_css`).
* ability to pick an existing shared theme and to reset to
blank theme. closes: CNVS-19685
* gets rid of jammit.
test plan:
(this is exaustive, so not every person has to do every step
but we should make sure at least someone does each of these things.
maybe as part of the review add a comment if you have done one of these
bulletpoints)
* before you check this out, compile all css and copy the
public/stylsheets_compiled directory somewhere. after you check out
this code and regenerate all the css. make sure there are no
significant changes to the css output. (we updated the versions of
node-sass and autoprefixer that we use so we want to make sure they
don't change things in a way we weren't expecting)
* make sure the way we load css for handlebars templates still works.
eg: if there is a handlebars template at
app/views/jst/some/template.handlebars
if there is also a scss file at
app/stylesheets/jst/some/template.scss
then that stylesheet should get loaded when that template is rendered
* check out the code and run migrations. browse around canvas,
make sure css and js files load correctly as before.
* cody, jacob, or someone on queso: look at the db migrations and
make sure everything looks good and that I am handling sharding
correctly.
* verify that both rake canvas:compile_assets and guard, works as well
as `node_modules/.bin/brandable_css` (note: if you have
"node_modules/.bin" in your PATH (which you should), it will also
work with just `brandable_css`)
* verify that passing the --watch option to
`.bin/node_modules/brandable_css` works and picks up changes to
sass files, images, fonts, or any other resource that goes into
a css file. and that it only recompiles the css files that actually
depend on that file.
* go to https://github.com/ryankshaw/brandable_css and check out the
code there. that is what is actually doing the sass compiling
* create a config/canvas_cdn.yml file and add aws access creds and
an s3 bucket and cdn hostname (for testing, you can use the credentials
for instructure_uploads_engineering from
https://gollum.instructure.com/OtherServiceTestAccounts ). for a test
cdn hostname you can use https://diu0rq5m1weh1.cloudfront.net. that
is a cloudfront bucket I set up on my personal account that points to
instructure_uploads_engineering
* run rake canvas:compile_assets again, this time, at the end, you
should see it run the assets:precompile task that puts md5s in filenames
and, gzipps them, and copys them to public/assets.
then you should see it run canvas:cdn:upload_to_s3
(look at log/development.log for progress),
which pushes everything to s3.
closes: CNVS-17333 CNVS-17430 CNVS-17337
* try out the theme editor: turn on new styles, go to accounts/x
(where x is the @domain root acount you are testing from) and click
the "theme editor" button on the right side of the page.
that should take you to a page that has the ability to pick colors/images
on the left side and preview your changes in an iframe on the right
closes: CNVS-19360 CNVS-20551
* test the "preview", "save", "reset", and "choose existing" functionality
closes: CNVS-17339 CNVS-17338 CNVS-19685
* make sure that the themeeditor works both if you have
config/canvas_cdn.yml set up and enabled as well as if you don't.
if it is enabled, you should see it push the css for just that new
brand config to s3 when you hit preview, and the css
should be accessible from the cdn you configured.
Change-Id: Ie0a812d04f5eeb40e7df7e71941ff63ea51a4d22
Reviewed-on: https://gerrit.instructure.com/53873
Tested-by: Jenkins
QA-Review: Jeremy Putnam <jeremyp@instructure.com>
Reviewed-by: Jacob Fugal <jacob@instructure.com>
Product-Review: Ryan Shaw <ryan@instructure.com>
2015-02-12 03:51:05 +08:00
|
|
|
/public/dist/
|
2013-01-22 01:16:29 +08:00
|
|
|
/public/doc/api/
|
2022-02-17 00:12:16 +08:00
|
|
|
/public/javascripts/translations/*
|
(i18n-js:5) flatten translation files
refs FOO-2801
flag = none
[change-merged][build-registry-path=jenkins/canvas-lms/foo-2801]
[pin-commit-analytics=4fd9e2fbb7fc2790ba7985bb4025e901bf33a9e3]
this part reaches the goal of this series where we turn the locale
files that are used by our JS engine into plain JSON files that don't
need any special processing and are also of a simpler structure
before, translations were stored in a tree structure that we needed to
traverse in order to look up a translation, which we did by
deconstructing keys through the "." operator:
I18n.lookup("foo.bar.baz")
{
en: {
foo: {
bar: {
baz: "Hello!" // <-- this
}
}
}
}
now, translations are stored in a flat dictionary structure where the
keys are not processed in any special way but are instead "fully
qualified":
I18n.lookup("foo.bar.baz")
{
en: {
"foo.bar.baz": "Hello!"
}
}
this is nice when you consider that the previous structure contained a
mixture of nested keys and flat ones, based on different conditions:
{
en: {
"asdf_1234": "ASDF", // inferred, so it was never "nested"
"foo": {
"bar": {
"baz": {
"one": "One banana",
"other": "Many many bananas"
}
}
}
}
}
because, for example, keys that are inferred by i18nliner end up at
the root level and not nested. You also never knew whether a key was a
container or a phrase that was pluralized, because they both had the
shape of an object.
Now these distinctions are gone; a key is always fully-qualified
regardless of how it was specified:
1) inferred: I18n.t("Inferred key")
// => inferred_key_c49e3743
2) absolute: I18n.t('#buttons.cancel')
// => buttons.cancel
3) relative: I18n = useScope('outer')
I18n.t('something', 'Something')
// => outer.something
4) nested: I18n = useScope('outer');
I18n.t('something.inside', 'Something inside')
// => outer.something.inside
5) pluralized: I18n.t({
one: 'One banana',
other: 'Many bananas'
})
// => many_many_bananas_ce8e7fb7.one
// => many_many_bananas_ce8e7fb7.other
Change-Id: I7c33fbd2321d7d56994223d65f2572db0ac12ed5
Reviewed-on: https://gerrit.instructure.com/c/canvas-lms/+/293675
Tested-by: Service Cloud Jenkins <svc.cloudjenkins@instructure.com>
QA-Review: Charley Kline <ckline@instructure.com>
Reviewed-by: Charley Kline <ckline@instructure.com>
Product-Review: Charley Kline <ckline@instructure.com>
2022-06-20 00:41:34 +08:00
|
|
|
!/public/javascripts/translations/en.json
|
2020-11-18 03:27:40 +08:00
|
|
|
/storybook-static/
|
2020-03-16 20:23:58 +08:00
|
|
|
/tmp/*
|
|
|
|
|
!/tmp/.keep
|
2022-02-19 00:42:40 +08:00
|
|
|
/vendor
|
2017-09-14 06:01:14 +08:00
|
|
|
yarn-error.log
|
2022-02-19 00:42:40 +08:00
|
|
|
dump.rdb
|
2022-10-15 19:15:21 +08:00
|
|
|
.eslintcache
|
2023-04-28 01:26:48 +08:00
|
|
|
tsconfig.tsbuildinfo
|
2013-01-22 01:16:29 +08:00
|
|
|
|
2014-10-16 02:50:10 +08:00
|
|
|
# canvas-gems
|
2014-04-20 16:22:49 +08:00
|
|
|
/gems/*/coverage
|
|
|
|
|
/gems/*/tmp
|
2016-05-27 07:39:09 +08:00
|
|
|
/gems/*/node_modules
|
2021-02-25 06:26:59 +08:00
|
|
|
/gems/plugins/*
|
2021-02-09 04:18:53 +08:00
|
|
|
!/gems/plugins/academic_benchmark/
|
|
|
|
|
!/gems/plugins/account_reports/
|
|
|
|
|
!/gems/plugins/moodle_importer/
|
|
|
|
|
!/gems/plugins/qti_exporter/
|
|
|
|
|
!/gems/plugins/respondus_soap_endpoint/
|
|
|
|
|
!/gems/plugins/simply_versioned/
|
2016-09-23 02:42:34 +08:00
|
|
|
|
|
|
|
|
# user docker compose overrides
|
2016-11-23 03:43:39 +08:00
|
|
|
docker-compose.local.*
|
2023-03-29 04:19:19 +08:00
|
|
|
!/inst-cli/docker-compose/docker-compose.local.dev.yml
|
2021-08-17 03:02:28 +08:00
|
|
|
# experimental api gateway config
|
|
|
|
|
docker-compose/api-gateway.override.yml
|
2017-12-18 22:39:39 +08:00
|
|
|
|
|
|
|
|
# sub-packages
|
|
|
|
|
/packages/*/node_modules
|
2019-05-04 14:59:37 +08:00
|
|
|
/packages/*/es
|
2019-08-08 23:09:48 +08:00
|
|
|
/packages/*/lib
|
2019-05-24 01:18:23 +08:00
|
|
|
/packages/*/coverage/
|
2021-08-27 01:00:25 +08:00
|
|
|
/packages/*/coverage-js/
|
2018-05-10 06:02:25 +08:00
|
|
|
|
|
|
|
|
# pact artifacts
|
|
|
|
|
/reports/
|
|
|
|
|
/pacts/
|
2018-05-15 05:32:44 +08:00
|
|
|
|
2020-11-06 05:49:40 +08:00
|
|
|
# generated scopes
|
|
|
|
|
/lib/api_scope_mapper.rb
|
|
|
|
|
|
2018-04-06 05:27:42 +08:00
|
|
|
# generated scopes markdown
|
|
|
|
|
/doc/api/api_token_scopes.md
|
|
|
|
|
|
|
|
|
|
# js coverage stuff
|
|
|
|
|
.nyc_output
|
|
|
|
|
coverage-jest
|
|
|
|
|
coverage-karma
|
2020-01-06 23:04:11 +08:00
|
|
|
|
|
|
|
|
# generated graphql schema
|
|
|
|
|
schema.graphql
|
2021-03-31 00:07:50 +08:00
|
|
|
|
|
|
|
|
# Ignore master key for decrypting credentials and more.
|
|
|
|
|
/config/master.key
|