panda_pal 5.0.0.beta.3 → 5.2.1

checksums.yaml

@@ -1,7 +1,7 @@
 ---
 SHA256:
-  metadata.gz: f40ed131f1e4a21e4b2f804bddb0df1500b7594fb7ddf07e5f8fca3bbe02a7c6
-  data.tar.gz: e27d2f357d57b7dc72952acf7a3d345b39614a5a617a0888737046abbf3f2bae
+  metadata.gz: 88fe8cce75e1f511b08e025ca0f00ab9cb224e9ab9c91f4a6f36fbbef6031f26
+  data.tar.gz: 9b23a25becc266908e081985943a9b51a5b856b7b52c8c948e007ad638ce90a9
 SHA512:
-  metadata.gz: f6b6dbbcf85c11363e459916df1f0569f9c905ac473d852681bb83e76ec00baa350c531150dc59760c5d0fdd498bcf2c50862f3dbfb5e3d5f0039624aa74d088
-  data.tar.gz: de4c5fd317349625e49e826e622f91b245464f99b1301fe42fbb5ff0a2b8809e4e59f7babe13f0b73cc487db92440d9451d722b784f94d590b58b83ec19d8d7c
+  metadata.gz: 5b82a6629e5d87d9420263eff1a57c477c9e1786fd91312354d8de41c0eba1e83968e4bf954691cb17eb09e6e5fc1f73284f08c76574ec459329ec5c5093d9c2
+  data.tar.gz: 86c997d27d7de28fd3be87bd9343c06ec5cfbf35a1559b2f131f068315b883449b58049b23ccba31e99524a32cef3132ff12ac50777a098821c17bbbe445a2e6

data/README.md

@@ -11,7 +11,12 @@ PandaPal.lti_properties = {oauth_compliant: 'true'}
 PandaPal.lti_environments = { domain: ENV['PROD_DOMAIN'], beta_domain: ENV['BETA_DOMAIN'], test_domain: ENV['TEST_DOMAIN'] }
 PandaPal.lti_custom_params = { custom_canvas_role: '$Canvas.membership.roles' }
 # :user_navigation, :course_navigation for user context and course context endpoints respectively
-PandaPal::stage_navigation(:account_navigation, { enabled: true, text: 'Teacher Reports', visibility: 'admins' })
+PandaPal::stage_navigation(:account_navigation, {
+  enabled: true,
+  # url: :account_index, # Optional if using lti_nav
+  text: 'Teacher Reports',
+  visibility: 'admins',
+})
 ```
 
 Configuration data for an installation can be set by creating a `PandaPal::Organization` record.  Due to the nature of the data segregation, once created, the name of the organization should not be changed (and will raise a validation error).
@@ -28,16 +33,50 @@ Use one of these 6 options in `PandaPal.lti_options` hash.
 5. Leave this property off, and you will get the dynamic host with the root path ('http://appdomain.com/') by default.
 6. If you really do not want this property use the option `launch_url: false` for it to be left off.
 
-# Organization Attributes
-  id: Primary Key
-  name: Name of the organization. Used to on requests to select the tenant
-  key: Key field from CanvasLMS
-  secret: Secret field from CanvasLMS
-  canvas_account_id: ID of the corresponding Canvas account.
-  settings: Hash of settings for this Organization
-  salesforce_id: ID of this organization in Salesforce
+### Task Scheduling
+`PandaPal` includes an integration with `sidekiq-scheduler`. You can define tasks on an Organization class Stub like so:
+```ruby
+# <your_app>/app/models/panda_pal/organization.rb
+require File.expand_path('../../app/models/panda_pal/organization.rb', PandaPal::Engine.called_from)
+
+module PandaPal
+  class Organization
+    # Will invoke CanvasSyncStarterWorker.perform_async() according to the cron schedule
+    scheduled_task '0 15 05 * * *', :identifier, worker: CanvasSyncStarterWorker
+
+    # Will invoke the method 'organization_method' on the Organization
+    scheduled_task '0 15 05 * * *', :organization_method_and_identifier
 
-XML for an installation can be generated by visiting /lti/config in your application.
+    # If you need to invoke the same method on multiple schedules
+    scheduled_task '0 15 05 * * *', :identifier, worker: :organization_method
+
+    # You can also use a block
+    scheduled_task '0 15 05 * * *', :identifier do
+      # Do Stuff
+    end
+
+    # You can use a Proc (called in the context of the Organization) to determine the schedule
+    scheduled_task -> { settings[:cron] }, :identifier
+
+    # You can specify a timezone. If a TZ is not coded and settings[:timezone] is present, it will be appended automatically
+    scheduled_task '0 15 05 * * * America/Denver', :identifier, worker: :organization_method
+
+    # Setting settings[:task_schedules][:identifier] will override the code cron schedule. Setting it to false will disable the Task
+    # :identifer values _must_ be unique, but can be nil, in which case they will be determined by where (lineno etc) scheduled_task is called
+  end
+end
+```
+
+### Organization Attributes
+  `id`: Primary Key
+  `name`: Name of the organization. Used to on requests to select the tenant
+  `key`: Key field from CanvasLMS
+  `secret`: Secret field from CanvasLMS
+  `canvas_account_id`: ID of the corresponding Canvas account.
+  `settings`: Hash of settings for this Organization
+  `salesforce_id`: ID of this organization in Salesforce
+
+XML for an installation can be generated by visiting `/lti/config` in your application.
 
 ### Routing
 
@@ -46,7 +85,7 @@ The following routes should be added to the routes.rb file of the implementing L
 ```ruby
 # config/routes.rb
 mount PandaPal::Engine, at: '/lti'
-lti_nav account_navigation: 'accounts#launch'
+lti_nav account_navigation: 'accounts#launch' # Use lti_nav to provide a custom Launch implementation, otherwise use the url: param of stage_navigation to let PandaPal handle launch.
 root to: 'panda_pal/lti#launch'
 ```
 
@@ -81,9 +120,10 @@ It is also possible to switch tenants by implementing `around_action :switch_ten
 However, it should be noted that calling `switch_tenant` must be used in an `around_action` hook (or given a block), and is only intended to be used for LTI launches, and not subsequent requests.
 
 ### Rake tasks and jobs
-# Delayed Job Support has been removed. This allows each project to assess it's need to handle background jobs.
+**Delayed Job Support has been removed. This allows each project to assess it's need to handle background jobs.**
+
 The Apartment Gem makes it so background jobs need to be run within the current tenant. If using sidekiq, there is a gem that
-does this automatically called apartment-sidkiq. If Delayed Jobs, see how it's done in version 1 of PandaPal.
+does this automatically called `apartment-sidkiq`. If Delayed Jobs, see how it's done in version 1 of PandaPal.
 
 For rake tasks, the current tenant will be set to `public`, and thus special handling must be taken when running the task or queueing jobs as part of it.
 
@@ -125,25 +165,52 @@ Controllers will automatically have access to a number of methods that can be he
 * `save_session` - Saves the session given by `current_session` to the database.
 
 ## Sessions and `current_session`
-A session_key returned by `current_session` is essentially an access token, and while we can't prevent users from sharing if they're so inclined, it should still be kept hidden as much as possible (namely by not including it as a URL param at any time).
-A good way to pass the `session_key` if using ajax or something similar, is to define it as a header in `$.ajaxSetup`.  This is particularly useful if a javascript framework such as React is being utilized.
+Because of the ever-increasing security around `<iframe>`s and cookies, a custom session implementation has been rolled into `PandaPal`.
+The implementation is mostly passive, but requires some changes and caveats as opposed to the native Rails implementation.
 
-PandaPal provides a number of ways to find a session, shown in the example below
+The current session object can be accessed from any controller using `current_session`. This object isn't the actual data container (as `session` _is_ in Rails).
+Session data can be accessed and modified using `current_session.data[:key]` or `current_session_data[:key]`.
 
-```ruby
-def session_key
-  params[:session_key] || session_key_header || flash[:session_key] || session[:session_key]
-end
+Because cookies are unreliable, it becomes the responsibility of the LTI developer to ensure that a custom "cookie" is passed to the frontend with each response
+and returned to the backend with each request, otherwise the backend won't be able to access the current session. There are a few ways to do this.
 
-def session_key_header
-  if match = request.headers['Authorization'].try(:match, /token=(.+)/)
-    match[1]
-  end
-end
+Generally, the method for passing the session "cookie" to the frontend looks something like:
+```html
+<meta name="session_key" content="<%= current_session.session_key %>">
+```
+
+### Returning to the backend
+The `session_key` can be passed to the backend in multiple ways:
+1. (Recommended) Via the `Authorization` Header (usually defining it as a default in your AJAX/XHR/`fetch` library):
+  ```http
+  Authorization: token=SESSION_KEY_HERE
+  ```
+2. Via a `session_key` parameter in a `POST` request (Useful for native HTML `<form>`s).
+3. (Used for Dev, but not highly discouraged in Prod) via a `GET`/URL Query parameter: `?session_key=SESSION_KEY_HERE`.
+
+The `session_key` does not contain any secrets itself, so it is safe to pass to the frontend, but it is encouraged to keep it away from the
+end-user as much as possible because it should not be shared.
+
+### Redirecting and Multi-Page Applications
+Special instructions must be followed when using `link_to` or `redirect_to` to ensure that the Session is passed correctly:
+
+Add a `session_token:` (notice the use of _`_token`_ as opposed to _`_key`_!) parameter when using `link_to` or `redirect_to`:
+```ruby
+  link_to "Link Name", somewhere_else_path(session_token: link_nonce)
+  redirect_to somewhere_else_path(session_token: link_nonce)
+```
+You can also use the `redirect_with_session_to` helper, which will automatically add `organization_id:` and `session_token:` params:
+```ruby
+  redirect_with_session_to :somewhere_else_path, other_param: 1
 ```
+For each request (not each call), `link_nonce` generates a nonce and stores it in the Session. The generated value can be used
+for at-most-one future request. This means that browser back-forward navigation **will not work** (if it actually ever worked for
+iframe-based LTIs in the first place).
 
 ### Persisting the session
-In order to reduce the number of sessions saved to the database, a session should only be saved if data has been added to it.  A good way to accomplish this is to add `append_after_action :save_session, if: proc { session_changed? }` to the application_controller.rb
+The session is automatically saved using an `after_action` callback. This callback is poised to run last, but if that causes issues
+(eg some other callback running afterwards and needing to modify the session), `skip_after_action :auto_save_session` can be used
+and a custom implementation can be supplemented.
 
 ### Session cleanup
 Over time, the sessions table will become bloated with sessions that are no longer active.
@@ -151,11 +218,6 @@ As such, `rake panda_pal:clean_sessions` should be run periodically to clean up
 
 ## Organizations and `current_organization`
 Similar to `current_session`, `current_organization` can be returned with a number of methods, shown below
-```ruby
-def organization_key
-  params[:oauth_consumer_key] || params[:organization_id] || current_session_data[:organization_key] || session[:organization_key]
-end
-```
 
 ## Security
 
@@ -179,56 +241,62 @@ It can be overridden on a action-by-action basis by using `skip_before_action`.
 skip_before_action :forbid_access_if_lacking_session, only: :launch
 ```
 
-### Upgrading to version 3
-
-Before upgrading save existing settings somewhere safe in case you need to
-restore them for whatever reason.
-
-panda_pal v3 introduces an encrypted settings hash.  This should provide more security in the case where a
-customer may have gained access to Organization information in the database.  Settings cannot be decrypted
-without knowing the secret decryption key.  For panda_pal, we are relying on the secret_key_base to be set
-(typically in config/secrets.yml), if that is not available we are falling back to directly use
-ENV['SECRET_KEY_BASE'].  For production environments, config/secrets.yml should not have a plain-text secret,
-it should be referencing an ENV variable.  Make sure your secret is not plain-text committed to a repository!
-
-The secret key is used to encrypt / decrypt the settings hash as necessary.
-
-Before upgrading to version 3, you should confirm that the secret key is set to a consistent value (if the
-value is lost your settings will be hosed).
-
-You should also rollback any local encryption you have done on the settings hash.  The settings hash
-should just be plainly visible when you upgrade to V3.  Otherwise the panda_pal migrations will
-probably fail.
-
-Once you have upgraded your gem, you will need to run migrations.  Before doing that, I would store off your
-unencrypted settings (just in case).
-
-`rake db:migrate`
-
-If all goes well, you should be set!  Log into console, and verify that you can still access settings:
-
-`PandaPal::Organization.first.settings`
-
-should show unencrypted settings in your console.
-
-If anything goes wrong, you should be able to rollback the change:
-
-`rake db:rollback STEP=2`
-
-If you need to give up on the change, just make sure to change your gem version for panda_pal to be < 3.
+### Secure Headers
+PandaPal bundles the `secure_headers` Gem and provides a default config. The PandaPal default works for really basic apps, but you may need to provide
+a custom configuration. This can be done by creating a `secure_headers.rb` initializer in you App like so:
+```ruby
+SecureHeaders::Configuration.default do |config|
+  PandaPal::SecureHeaders.apply_defaults(config) # Optional, but recommended
+  # ...
+end
+```
 
-### Validating settings in your LTI.
+## Validating settings in your LTI.
 
 You can specify a structure that you would like to have enforced for your settings.
 
-In your panda_pal initializer (i.e. config/initializers/panda_pal.rb or config/initializers/lti.rb)
+In your panda_pal initializer (i.e. `config/initializers/panda_pal.rb` or `config/initializers/lti.rb`)
 
 You can specify options that can include a structure for your settings.  If specified, PandaPal will
 enforce this structure on any new / updated organizations.
 
+```ruby
+PandaPal.lti_options = {
+  title: 'LBS Gradebook',
+  settings_structure: {
+    allow_additional: true, # Allow additional properties that aren't included in the :properties Hash.
+    allow_additional: { type: 'String' }, # You can also set :allow_additional to a settings specification that will be used to validate each additional setting
+    validate: ->(value, spec, **kwargs) {
+      # kwargs currently includes:
+      #   :errors => [An array to push errors to]
+      #   :path => [An array representation of the current path in the settings object]
+
+      # To add errors, you may:
+      # Push strings to the kwargs[:errors] Array:
+      kwargs[:errors] << "Your error message at <path>" unless value < 10
+      # Or return a string or string array:
+      value.valid? ? nil : "Your error message at <path>" # <path> will be replaced with the actual path that the error occurred at
+    },
+    properties: {
+      canvas_api_token: { type: 'String', required: true, },
+      catalog: { # :validate, :allow_additional, :properties keys are all supported at this level as well
+        type: 'Hash',
+        required: false,
+        validate: -> (*args) {},
+        allow_additional: false,
+        properties: {
+
+        },
+      }
+    }
+  },
+}
+```
+
+#### Legacy Settings Structure:
 Here is an example options specification:
 
-```
+```ruby
 PandaPal.lti_options = {
   title: 'LBS Gradebook',
   settings_structure: YAML.load("
@@ -271,9 +339,41 @@ This is determined by `PandaPal.lti_options[:platform]`.
 Set this to `platform: 'canvas.instructure.com'` (default)
 OR `platform: 'bridgeapp.com'`
 
-### Safari Support
+## Development:
+### Running Specs:
+Initialize the Specs DB:
+`cd spec/dummy; bundle exec rake db:drop; bundle exec rake db:create; bundle exec rake db:schema:load`
+Then `bundle exec rspec`
+
+## Safari Support
+Safari is weird (it blocks cookies in `<iframe>`s unless the site has set a cookie _outside_ of an `<iframe>` first), and you'll run into
+issues with Rails-native Sessions and CSRF because of that.
 
-Safari is weird, and you'll potentially run into issues getting `POST` requests to properly validate CSRF if you don't do the following:
+This means that safari will likely refuse to send info about your rails session
+back to the LTI, and the application will start up a new session each time the
+browser navigates.  This likely means a new session each time the LTI launches.
+
+### PandaPal 5
+It has been a constant struggle to force safari to store and allow
+access to a rails session while the application is embedded in Canvas.
+
+As of PandaPal 5, a session cookie is no longer required by panda_pal.
+
+See the Section on [Sessions and `current_session`](#sessions-and-current_session)
+
+You will want to watch out for a few scenarios:
+1) Make sure you are using `redirect_with_session_to` if you need to redirect
+   and have your PandaPal session_key persisted server side.
+2) Use the `Authorization` header with `token={session_key}` to send your
+   PandaPal session info into api calls.
+3) If you use `link_to` and navigate in your LTI (apps that are not single page)
+   make sure you include the `link_nonce` like so: 
+    ```ruby
+      link_to "Link Name", somewhere_else_path(session_token: link_nonce)
+    ```
+
+### Previous Safari Instructions
+Safari is weird and you'll potentially run into issues getting `POST` requests to properly validate CSRF if you don't do the following:
 
 - Make sure you have both a `launch` controller and your normal controllers. The `launch` controller should call `before_action :validate_launch!` and then redirect
   to your other controller.
@@ -281,49 +381,47 @@ Safari is weird, and you'll potentially run into issues getting `POST` requests
 
 This will allow `PandaPal` to apply an iframe cookie fix that will allow CSRF validation to work.
 
+## Migrating Major Versions
 
-### PandaPal 5
+### Upgrading to version 3
 
-It has been a constant struggle to force safari to store and allow
-access to a rails session while the application is embedded in Canvas.
+Before upgrading save existing settings somewhere safe in case you need to
+restore them for whatever reason.
 
-As of PandaPal 5, a forced persistent session is now optional, and defaults to off.
+panda_pal v3 introduces an encrypted settings hash.  This should provide more security in the case where a
+customer may have gained access to Organization information in the database.  Settings cannot be decrypted
+without knowing the secret decryption key.  For panda_pal, we are relying on the secret_key_base to be set
+(`typically in config/secrets.yml`), if that is not available we are falling back to directly use
+`ENV['SECRET_KEY_BASE']`.  For production environments, `config/secrets.yml` should not have a plain-text secret,
+it should be referencing an ENV variable.  Make sure your secret is not plain-text committed to a repository!
 
-This means that safari will likely refuse to send info about your rails session
-back to the LTI, and the application will start up a new session each time the
-browser navigates.  This likely means a new session each time the LTI launches.
+The secret key is used to encrypt / decrypt the settings hash as necessary.
 
-You will want to watch out for a few scenarios:
+Before upgrading to version 3, you should confirm that the secret key is set to a consistent value (if the
+value is lost your settings will be hosed).
 
-1) Make sure you are using "redirect_with_session_to" if you need to redirect
-   and have your PandaPal session_key persisted server side.
-2) Use the "Authorization" header with "token={session_key}" to send your
-   PandaPal session info into api calls.
+You should also rollback any local encryption you have done on the settings hash.  The settings hash
+should just be plainly visible when you upgrade to V3.  Otherwise the panda_pal migrations will
+probably fail.
 
-You can force a persistent session with -
-PandaPal.lti_options = {
-  require_persistent_session: true
-}
-in your config/initializer.  With that setting, the user will be required to
-allow our application to store / access cookies in safari before they can use
-the LTI.
+Once you have upgraded your gem, you will need to run migrations.  Before doing that, I would store off your
+unencrypted settings (just in case).
+
+`rake db:migrate`
+
+If all goes well, you should be set!  Log into console, and verify that you can still access settings:
+
+`PandaPal::Organization.first.settings`
 
-# Notes on require_persistent_session
+should show unencrypted settings in your console.
+
+If anything goes wrong, you should be able to rollback the change:
 
-IF you must have a persistent session this is the logical flow of how panda_pal
-attempts to set that up.
+`rake db:rollback STEP=2`
 
-1) LTI laumches.
-2) LTI will attempt to POST message from iframe to top window (canvas) telling
-   canvas to relaunch in full screen so we aren't inhibited by safari.
-3) LTI will setup session and cookies in full-screen mode.  Session will be saved
-   in browser.
-4) LTI will redirect to an authorization page, that will require user to give
-   access to the session store to our application.
-5) Once the user gives access to the session store, we will reload the LTI
-   and the cookie should now be persistent.
+If you need to give up on the change, just make sure to change your gem version for panda_pal to be < 3.
 
-# Upgrading from PandaPal 4 to 5:
+### Upgrading from PandaPal 4 to 5:
 
 If your tool is setup according to a pretty standard pattern (see pace_plans,
 canvas_group_enrollment, etc), you shouldn't have to do anything to upgrade.
@@ -333,7 +431,7 @@ using "redirect_with_session_to".
 
 Here is an example launch / account controller setup, assuming an account launch.
 
-```
+```ruby
 class LaunchController < ApplicationController
   # We don't verify CSRF on launch because the LTI launch is done via a POST
   # request, and Canvas wouldn't know anything about the CSRF
@@ -360,4 +458,3 @@ class AccountController < ApplicationController
   end
 end
 ```
-

data/app/controllers/panda_pal/lti_controller.rb

@@ -2,23 +2,5 @@ require_dependency "panda_pal/application_controller"
 
 module PandaPal
   class LtiController < ApplicationController
-    def tool_config
-      if PandaPal.lti_environments.empty?
-        render plain: 'Domains must be set in lti_environments'
-        return
-      end
-      platform = PandaPal.lti_options.delete(:platform) || 'canvas.instructure.com'
-      request_url = "#{request.scheme}://#{request.host_with_port}"
-      case platform
-      when 'canvas.instructure.com'
-        xml_config = LtiXml::CanvasPlatform.new(platform, request_url, main_app)
-      when 'bridgeapp.com'
-        xml_config = LtiXml::BridgePlatform.new(platform, request_url, main_app)
-      else
-        render plain: 'platform must be set under lti_options'
-        return
-      end
-      render xml: xml_config.xml
-    end
   end
 end

data/app/controllers/panda_pal/lti_v1_p0_controller.rb

@@ -0,0 +1,34 @@
+require_dependency "panda_pal/application_controller"
+
+module PandaPal
+  class LtiV1P0Controller < ApplicationController
+    def launch
+      current_session_data.merge!({
+        lti_version: 'v1p0',
+        lti_launch_placement: params[:launch_type],
+        launch_params: params.to_unsafe_h,
+      })
+
+      redirect_with_session_to(:"#{LaunchUrlHelpers.launch_route(params[:launch_type])}_url", route_context: main_app)
+    end
+
+    def tool_config
+      if PandaPal.lti_environments.empty?
+        render plain: 'Domains must be set in lti_environments'
+        return
+      end
+      platform = PandaPal.lti_options.delete(:platform) || 'canvas.instructure.com'
+      request_url = "#{request.scheme}://#{request.host_with_port}"
+      case platform
+      when 'canvas.instructure.com'
+        xml_config = LtiXml::CanvasPlatform.new(platform, request_url, main_app)
+      when 'bridgeapp.com'
+        xml_config = LtiXml::BridgePlatform.new(platform, request_url, main_app)
+      else
+        render plain: 'platform must be set under lti_options'
+        return
+      end
+      render xml: xml_config.xml
+    end
+  end
+end