I am trying to get my head around it trying to figure out why one of my non-administrative user has absolutely no access to the contents of all his courses (or about pages for these same courses) while an administrative account has no issue. Is there a specific setting to allow course access for all users now? It definitely looks like a permission issue.
Based on the courseware decisions mentioned above, shall I assume we need a tutorial on bridgekeeper? Maybe I am totally wrong too…
When in doubt, I always go back to a default single server installation with the open-release branch of edX. It allows me to see if the behaviour in our fork is different than the behaviour with that branch.
In this case, I see the Demo Course in the catalog. I cannot see the about page when I click on the course. The users staff, audit, honor and verified are all registered in this course. All have the course in their respective dashboard. Only the user staff can access the contents of the course. The other users get “The page that you were looking for was not found. Go back to the homepage or let us know about any pages that may have been moved at technical@example.com.” Also, only the staff user can see courses/course-v1:edX+DemoX+Demo_Course/about and only if authenticated.
What am I doing wrong? At least I know the problem does not seem to be related to our fork of Open edX only because I was able to replicate it in a single server installation with the open-release/juniper.alpha1 from edX.
Any suggestions or pointers that could allow me to have users access their courses?
Shall I open a CRI (Community Reported Incident) ticket in JIRA?
I might have found a problem on our side because if I connect directly to a server then I am able to access the about page without being authenticated and the contents of the demo course through port 80 after being authenticated.
Unfortunately, if I then connect the server through an ELB then I have the problems I encountered before.
I wonder if something changed at the Nginx level between Ironwood and Juniper. I will investigate more in the coming days. And obviously make it work through https too.
@sambapete Are the instances behind your load balancer protected by basic auth by any chance?
I haven’t tried Juniper Alpha yet, so have no idea if this is related, but we had a similar-sounding issue with access to some of the API calls used by the mobile app. We resolved that by using Django Admin to add a DOT application entry containing the basic authentication credentials. See edx-platform#19571 for context, and configuration#4937 which wasn’t merged.
At first hand, it looks more like a problem on our side. I have to better understand why something that worked with Ironwood and our ELB is no longer working with Juniper. We already moved to ALB in our test and production environments so I am little baffled by the fact this is the previous production ELB that does not work anymore. I will look into that today.
I can’t explain it but now that I moved from an ELB to an ALB in the AWS region where we are testing Juniper, everything is back to normal.
I must assume there was something wrong either in my ELB or in some rewriting rules in Nginx on the server side.
Problem fixed. Sorry for the annoyance.
False positive… It worked for a few minutes and it stopped working after a new installation. There must be a specific case or rules I need to tweak. I am getting very annoyed.
I did find something after you posted your message. I guess it is due to changes between the new /edx/etc/lms.yml and the way I had set up lms.env.json and lms.auth.json under ironwood. I will get back to you early next week.
An update for you @nedbat
I found the right settings for /edx/etc/lms.yml. Everything worked. I save that file and make a copy in order to test something.
I change a value in /edx/etc/lms.yml. It does not work anymore.
I put back the working configuration I saved earlier. It does not work anymore…
I guess this is exactly what happened yesterday when it was working and suddenly it wasn’t working anymore. I did execute reload_lms_config.sh each time I modified or copied /edx/etc/lms.yml. So you can find me totally surprised that the configuration that worked stopped working. I guess I will start again from the start on Monday.
After a few hours poking at the problem on Saturday and Sunday, it looks more like a bad / strange combination of /edx/etc/lms.yml configuration, /edx/app/nginx/sites-available/lms customized nginx rules and AWS ALB listeners rules.
Everything is fine now. But I ended up recompiling my assets and rebooting the server every time I made a change in /edx/etc/lms.yml in order to pinpoint the issue. Changing a line in /edx/etc/lms.yml, recompiling the assets, rebooting, testing the access, goto “Changing a line in /edx/etc/lms.yml”.
I am currently wondering if reload_lms_config.sh works as I expected. Maybe. Maybe not. I think I will stay with the good old recompile the assets and restart the services for now like I was doing before whenever I made a change in lms.env.json, cms.env.json, lms.auth.json or cms.auth.json.
@nedbat please put https://openedx.atlassian.net/browse/CRI-172 on hold for now. I now have to make sure all other services we use (ecommerce, course discovery, others) are still working with JWT and oauth2.
toxinu
(Geoffrey L. (OpenCraft) - opencraft.com/help)
10
@sambapete Just getting some news about this issue (CRI-172). Does it sound fixed from your side or should we invest more time to debug it?
I have not been thinking of this issue since the last time I tried juniper.alpha1 back in early February. Reading the thread on this post I guess it was fixed or a combination of different misconfigurations on our side. But now that juniper.rc1 is out, I might need to take another look at it. I might get back to you in the next few days. For now, let’s leave it on hold. Thanks.
I no longer have this issue. It was probably a misconfiguration between /edx/etc/lms.yml, /edx/app/nginx/sites-available/lms and my AWS ALB listeners rules.