its possible login to course with parameter
for example
https://mymoodle/mylocation/myfile.php?username=myuser&password=mypass
thanks
I don't think it's possible, and it's probably not a good idea to allow that. Why do you want to do this?
my customer need login direct to moodle from another plataform. thx for your answer
If a direct Course URL is provided and If the course is restricted to registered users, it will prompt for a Username/Password combination. When these are correctly submitted and the user is authenticated then it will go to the course.
Otherwise it's not easily possible out of the box. We have developed a custom solution to this problem, however I am not able to share the source of that just yet unfortunately, but I hope that situation will change soon. It's basically a simplified SSO system.
In a nutshell it's a PHP script that accepts posted variables; Username, Password, IV (initialisation vector; all details are AES encrypted) and URL. Uses these details and authenticates using Moodle functions and when successfully authenticated redirects the user to the URL given. There are checks to make sure that URL is only inside Moodle itself, and in most cases the redirect occurs sending the user to a Course.
All in all it's not difficult to implement with some knowledge of Moodle internals, if you read the source of the /login/index.php page you should be on your way to understanding how to implement a custom solution.
Otherwise it's not easily possible out of the box. We have developed a custom solution to this problem, however I am not able to share the source of that just yet unfortunately, but I hope that situation will change soon. It's basically a simplified SSO system.
In a nutshell it's a PHP script that accepts posted variables; Username, Password, IV (initialisation vector; all details are AES encrypted) and URL. Uses these details and authenticates using Moodle functions and when successfully authenticated redirects the user to the URL given. There are checks to make sure that URL is only inside Moodle itself, and in most cases the redirect occurs sending the user to a Course.
All in all it's not difficult to implement with some knowledge of Moodle internals, if you read the source of the /login/index.php page you should be on your way to understanding how to implement a custom solution.
i implement ugly solution but work..
if(!empty($_GET['username'])&&!empty($_GET['password'])){
$_POST['username'] = addslashes($_GET['username']);
$_POST['password'] = addslashes($_GET['password']);
}
require_once("../config.php");
if( isset($_GET['course']) && !empty($_GET['course'])){
$SESSION->wantsurl = $CFG->wwwroot.'/course/view.php?id='.addslashes($_GET['course']);
}
on /login/index.php, if any have another solution please share
And you can access by: http://mymoodle/login/index.php?course=2&username=test&password=test
And http://mymoodle/login/index.php
sorry my english
if(!empty($_GET['username'])&&!empty($_GET['password'])){
$_POST['username'] = addslashes($_GET['username']);
$_POST['password'] = addslashes($_GET['password']);
}
require_once("../config.php");
if( isset($_GET['course']) && !empty($_GET['course'])){
$SESSION->wantsurl = $CFG->wwwroot.'/course/view.php?id='.addslashes($_GET['course']);
}
on /login/index.php, if any have another solution please share
And you can access by: http://mymoodle/login/index.php?course=2&username=test&password=test
And http://mymoodle/login/index.php
sorry my english
Looks like it might work and do what you expect, however I would STRONGLY suggest using at the very least SSL for the form submission, and if you can, encrypting (and base 64 encoding) the password before sending to the Moodle script.
I also assume what you've posted is something of a 'proof of concept' and not production code, because you should NEVER use $_GET and $_POST without sanitising the variable contents at the very least.
As it stands your script is very insecure and open to a number of vulnerabilities.
I also assume what you've posted is something of a 'proof of concept' and not production code, because you should NEVER use $_GET and $_POST without sanitising the variable contents at the very least.
As it stands your script is very insecure and open to a number of vulnerabilities.
yes is pof thx for your responses
Is there any reason you are implementing your own custom SSO from scratch instead of using Moodle Networks, Shibboleth, CAS, OpenID, or one of the other existing SSO solutions?
yes because i can't modify the client system, and my customer say
"i need connect by the specific url,please modify your plataform".. :S
"i need connect by the specific url,please modify your plataform".. :S
Well, my comment was more directed at James McLean...
But if your client is not willing to modify their system, and their system doesn't support any other solution, then I guess you're stuck, no matter what the security implications.
But if your client is not willing to modify their system, and their system doesn't support any other solution, then I guess you're stuck, no matter what the security implications.
Yes, I'll outline our reasons:
Moodle Networks:
We need SSO from a custom .NET system into Moodle, not Moodle->Moodle
Shibboleth:
The team previously had bad experiences with it, and decided not to investigate it in this instance.
CAS:
Was not aware of it, but having just searched for it and skimmed over some information it looks like it may have worked, however it's still a lot more complex than we needed.
OpenID:
We did not investigate it.
NTLM:
I read of issues where users with Firefox would need to enter a network username to authenticate in the form of <domain>\username. Far too much of a support headache for users who may not understand why they need to do it that way, not to mention the poor Help Desk team. Also, the additional Apache configuration required to get NTLM working on the server was not a burden I wanted to place on the Sysadmins who will maintain the servers.
I guess our system isn't "truly" single sign on, but at least to the user, it appears that way. It's using one simple PHP script on the Moodle side (just over 100 lines with comments) to accept the user details, some of our already existing functionality on the .NET side, completely cross browser and cross platform and no additional points of failure as with some other SSO systems, it was a no-brainer really.
Honestly to get it working was afternoons development between myself (the PHP guy) and our senior tech specialist (the .NET guy). It works very very well, uses two levels of strong encryption and has been nothing but 100% reliable so far. The biggest issue we had was making sure the .NET and Mcrypt libraries used the same block chaining and character padding when encrypting the password.
It's intended that this (and our many other changes) will be Open Sourced at sometime in the near future, however as I'm sure you can understand the decision of "when" comes from above in the halls of management and not the cubes of development
Thanks for the query however!
Moodle Networks:
We need SSO from a custom .NET system into Moodle, not Moodle->Moodle
Shibboleth:
The team previously had bad experiences with it, and decided not to investigate it in this instance.
CAS:
Was not aware of it, but having just searched for it and skimmed over some information it looks like it may have worked, however it's still a lot more complex than we needed.
OpenID:
We did not investigate it.
NTLM:
I read of issues where users with Firefox would need to enter a network username to authenticate in the form of <domain>\username. Far too much of a support headache for users who may not understand why they need to do it that way, not to mention the poor Help Desk team. Also, the additional Apache configuration required to get NTLM working on the server was not a burden I wanted to place on the Sysadmins who will maintain the servers.
I guess our system isn't "truly" single sign on, but at least to the user, it appears that way. It's using one simple PHP script on the Moodle side (just over 100 lines with comments) to accept the user details, some of our already existing functionality on the .NET side, completely cross browser and cross platform and no additional points of failure as with some other SSO systems, it was a no-brainer really.
Honestly to get it working was afternoons development between myself (the PHP guy) and our senior tech specialist (the .NET guy). It works very very well, uses two levels of strong encryption and has been nothing but 100% reliable so far. The biggest issue we had was making sure the .NET and Mcrypt libraries used the same block chaining and character padding when encrypting the password.
It's intended that this (and our many other changes) will be Open Sourced at sometime in the near future, however as I'm sure you can understand the decision of "when" comes from above in the halls of management and not the cubes of development
Thanks for the query however!
For reference, Moodle Networks is not just for Moodle->Moodle, as long as you are willing to dig into the protocol (which, admittedly, is quite a task). I have implemented the protocol in Java, and implemented a Moodle->JasperServer single sign-on.
Like you, my Java implementation will be open sourced at some point in the future, but the "when" will be determined by management (and the sometimes even more restrictive: "when we have time" element).
Like you, my Java implementation will be open sourced at some point in the future, but the "when" will be determined by management (and the sometimes even more restrictive: "when we have time" element).
So what and How exactly did you achieve the single sign on. We are currently working on similar project that requires SSO from .net to Moodle.
Greetings!
This sounds like something which might be able to help us implement a pseudo-SSO system between our university's portal and Moodle.
Has your management approved releasing any code?
Thanks!
You should not be storing user passwords in plain text, as that is a security risk. You should probably look into one of the other existing Single Sign-on solutions.
Agreed. Do not use the method we have discussed if you cannot encrypt the password with strong encryption.