I am Test manager for Canvas Implementation in RMIT University , Melbourne and I need some advice on testing with test student accounts.
Currently we have a set up which do not allow student accounts ( S numbers) to access canvas test environment ( and this is for security reasons). With this set up we are also unable to user our dummy test student accounts to perform test verification required for different releases.
Will be a huge favor if there are any advice on how to only enable the access for student dummy accounts on canvas test environment and isolate this from real student accounts ?
Hi @aurnob_bhattach ,
This would largely depend on a few factors. Can you please advise, how are you restricting the access for the S accounts, is this done programmatically via the API, at the Canvas level? Alternatively is this done through a mechanism in your authentication system?
I ask, as how you are restricting the accounts will have impacts on how you get around it. The mechanism we have employed is creating local logins for test accounts that need temporary access on the Test or Beta environments. After setting up a local login password on their account you can then use <yourinstance>.test.instructure.com/login/canvas to override the any other login method and log in with that account. This will help if you are using something on the authentication system to restrict their account.
If however, you are using a programmatic solution to explicitly disable their accounts via the API, that would require some additional wizardry.
Also, can you please advise what you mean by isolating the test accounts from real students? I am curious what you are trying to achieve here, and what you mean by segmenting?
Hope that helps, and I look forward to hearing from you.
Thanks a lot for the update. Really appreciate it.
The change on not allowing student accounts to access canvas test environment is done by Canvas and my understanding is that they have done it at role level ( as student) most probably via API but I have sent them an email confirming this.
What I mean by isolate test accounts and real student accounts is that we have separate series of S number which is used for testing and they are dummy accounts and easily differentiated from RMIT student accounts.
The suggestion - creating local logins for test accounts that need temporary access on the Test or Beta environments will that work if canvas has restricted student access on canvas test at role level ( student ) ?
Hi @aurnob_bhattach ,
Of course, indeed you are correct and I apologise for that feature slipping my mind when I first replied. It is a feature that you can opt to have turned off (for temporary periods of testing), and this is the option we have adopted at UTS.
However, that is not to say this is the only option. You could (using your authentication systems) potentially disable access for regular student accounts when the authentication mechanism attempts to connect from the non-prod URL. This would be entirely dependant on the backend authentication mechanism you use, and if you can achieve this, you could then leave the student login option permanently enabled.
The other way we have got around this is by using a 'Prod-Dev' environment. I outline this in these two posts https://community.canvaslms.com/message/94251-re-conditions-where-non-prod-systems-wont-work-for-lti... and https://community.canvaslms.com/thread/20173-prod-vs-test-and-best-practices-for-testing-changes#com... which I highly recommend a read of for additional options.
However, now that you mention this, I would like to float an idea, I am wondering if there is benefit in a new feature idea requesting an API endpoint to re-enable individual accounts on a case-by-case basis?
I could see this being exceptionally useful for just such an occasion and would make things somewhat more flexible. I would be curious to hear your thoughts?
Oh also, I have taken the liberty of sharing this with the https://community.canvaslms.com/groups/admins?sr=search&searchId=1d0c5829-2fe6-4888-a372-9cef3685a6b... and https://community.canvaslms.com/groups/canvas-developers?sr=search&searchId=3ea09d8a-c5ae-4bcc-881b-... groups as there may be a few people in these groups that could provide some additional angles on this for you!
Hope that helps!
Hi @aurnob_bhattach ,
A question, does your testing need you to authenticate directly to your test instance using the student test accounts? If you are an admin and have "Act as user permissions" you can act as the test user for testing purposes if needed. However, this approach does not work for all sorts of testing I guess (like testing LTI's)
Sorry for responding late, just caught up with test releases.
Option 1 - To potentially disable access for regular student accounts when the authentication mechanism attempts to connect from the non-prod URL. This would be entirely dependant on the backend authentication mechanism we use, and at this point of time its hard to achieve
Option 2 - I have gone through the article - https://community.canvaslms.com/thread/20173-prod-vs-test-and-best-practices-for-testing-changes#com... and we have a separate cluster too and we were using that only for notification testing as on canvas test and prod notifications are disabled. As that is a standalone instance it does not have the current prod config and all the other settings we gradually are making on canvas prod and we have to update that instance manually each time we change a prod config. The cloning cost from prod to this other instance (for testing) is not an ideal solution.
Hence this is possible but may be not exact replica of test as it does not get refreshed by prod version
Also we initially tried with creating a TEST SUBACCOUNT in canvas prod but that is not ideal for integration testing as we need to integrate non prod legacy system with non prod canvas env and validate before any prod release.
Hence I would second your idea as I had the same thought - new feature idea requesting an API endpoint to re-enable individual accounts on a case-by-case basis?
And this will be extremely helpful also test team can have control of which users have access to test account .
Thanks for your response.
You are right - Act as user is good for quick student view verification but not ideal for integration testing as we need to integrate non prod legacy system with non prod canvas env and validate before any prod release.
And that does not always give right results with Act as user.