Skip to content
This repository has been archived by the owner on Nov 28, 2017. It is now read-only.

Update jefreg.php #4

Open
wants to merge 1 commit into
base: master
Choose a base branch
from
Open

Conversation

mgilkes
Copy link

@mgilkes mgilkes commented Jan 21, 2014

The sessid GET variable was base64 encoded. It should not be. It will never be detected if it is.

The sessid GET variable was base64 encoded. It should not be. It will never be detected if it is.
@mgilkes
Copy link
Author

mgilkes commented Jan 21, 2014

Hi Don,

Thanks for emailing me.

I wanted to discuss that with someone, but wasn't sure who to contact. I was looking at the code and the session id is attached as part of the base64 encoded value for installfrom GET variable. I tried to figure out why that was done, and realized it was never used.

The only reference I see in the code to the session id as a get variable is in onAfterInitialise() and onAfterRoute() and onUserAfterLogin(). However, in each of these instances it is either being referenced or being removed. And they have a comment that says: 

// Retrieve $_SESSION data from the database if $_GET['sessid'] has a value
// Note: $_GET['sessid'] is set when the user backend requests file to install

However, the only time it actually exists as a GET variable assignment is in the getInstallFrom() method. And the problem I saw was that it was always being base64 encoded as part of the installfrom GET variable value, which didn't seem to make sense. You would never find it as a GET variable if it was base64 encoded as part of the installfrom GET variable value.

So that is why I have adjusted it to not be part of that value.

Let me know what you think.

Michael

On Tuesday, January 21, 2014 12:23 PM, Don Gilbert [email protected] wrote:

Why are we passing the session id? What is the purpose for that requirement?

Reply to this email directly or view it on GitHub.

@emavro
Copy link

emavro commented Jan 21, 2014

I'm afraid you'll have to look at the broader picture here and this includes the install-from-web-server and the install-from-web-client repository. You can't really understand how the plugin works until you've gone through the code in those two other repositories.

Let me elaborate on this...

  1. You start using the Install from Web tab in your site backend.
  2. You find an extension that requires registration.
  3. You are redirected to the developer's website. Your backend's URL is carried over to the developer's website through $_POST['installat']. The extension id (or whatever other information the developer has submitted to JED) is passed through $_POST['installapp'].
  4. You register and then these things happen (onUserAfterLogin):
    -- Your session information is checked.
    -- $_GET['installfrom'] is set in base64 encoding. It carries the URL for you to download your extension plus your session id.
    -- You are redirected back to your website, carrying over 'installfrom'.
  5. Your local Install from Web plugin decodes the value of $_GET['installfrom'] and sets it as the URL field value in the Install from URL tab.
  6. You are asked to confirm that you want to install the extension from the URL above.
  7. If you confirm, you are redirected back to the developer website where the plugin's onAfterInitialise function logs you in using your session id.
  8. The required file is retrieved.

I hope this helps to sort things out. Session ID is not needed at your own website that why it is encoded together with the rest of the URL. It is needed when you come back to grab the extension file. And by the time you come back to the developer site, it's already been decoded and used appropriately.

@mgilkes
Copy link
Author

mgilkes commented Jan 21, 2014

Thanks for clarifying that.

By, the way, one more question…

Joomla 2.5 does not have the onUserAfterLogin event. This was added in Joomla 3.2. Assuming that this plugin can be used in Joomla 2.5, how can we remedy this? onUserAfterLogin is never called if you are using a Joomla version lower than 3.2. How about using onUserLogin for those Joomla versions?

Let me know what you think.

Michael

On Tuesday, January 21, 2014 3:17 PM, emavro [email protected] wrote:

I'm afraid you'll have to look at the broader picture here and this includes the install-from-web-server and the install-from-web-client repository. You can't really understand how the plugin works until you've gone through the code in those two other repositories.
Let me explain how this works...
1. You start using the Install from Web tab in your site backend.
2. You find an extension that requires registration.
3. You are redirected to the developer's website. Your backend's URL is carried over to the developer's website through $POST['installat']. The extension id (or whatever other information the developer has submitted to JED) is passed through $POST['installapp'].
4. You register and then these things happen (onUserAfterLogin):
-- Your session information is checked.
-- $_GET['installfrom'] is set in base64 encoding. It carries the URL for you to download your extension plus your session id.
-- You are redirected back to your website, carrying over 'installfrom'.
5. Your local Install from Web plugin decodes the value of $_GET['installfrom'] and sets it as the URL field value in the Install from URL tab.
6. You are asked to confirm that you want to install the extension from the URL above.
7. If you confirm, you are redirected back to the developer website where the plugin's onAfterInitialise function logs you in using your session id.
8. The required file is retrieved.
I hope this helps to sort things out. Session ID is not needed at your own website that why it is encoded together with the rest of the URL. It is needed when you come back to grab the extension file. And by the time you come back to the developer site, it's already been decoded and used appropriately.

Reply to this email directly or view it on GitHub.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants