pnCPG & xp_publish

[TheGamer1701]

Hello,

I have problems with some users and the xp_publish.php file.
Well, when user register in postnuke and then visit cpg, the user is created in cpg, too.
That works great.
But, it seems that pnCPG uses a cpg foreign password encryption, which cpg doesn't know.
So whenever a user tries to log in through the xp_publish wizard, he get's an error (although the password might be right).

So, the problem is, that pnCPG saves the passwords only encrypted, but xp_publish either waits for the clear passwords or for the cpg encryption.
Do you have any idea for an workaround?
Maybe you could point me to the function, I guess I could fix the xp_publish then.

System:
PostNuke 0726
Coppermine Standalone 1.4.3
pnCPG bridge v 3.1


Greetz,
André

[Joachim Müller]

http://coppermine-gallery.net/demo/cpg14x/docs/index.htm#upload_trouble

[TheGamer1701]

http://coppermine-gallery.net/demo/cpg14x/docs/index.htm#upload_trouble

Sorry GauGau, but I know the docs and troubleshooting, too.
But I also know, that this is definetly a problem with pnCPG storing the password encrypted in the database instead of storing it as it is.

Okay, here is an example:
Let's say I've got 2 Accounts, both have the password "enterprise".
Account1 now has the following in the _users table:
(I'm leaving out most of the fields)
user_id | user_name | user_password
1 | Account1 | enterprise

Well, but for the 2nd Account it looks different:
user_id | user_name | user_password
2 | Account2 | LrEfGVQr


Okay, what's the difference between those 2 Accounts?
Simple...
Account1 is the admin Account created during installation, but Account 2 has been imported from PostNuke using the pnCPG Module.

So, how could we fix this?
It seems to me that PostNuke is storing all passwords only md5 encrypted, so I guess there is no way to store the real password in cpg, but I guess we could alter the xp_publish and cpg_login files to work with pnCPG (of course just for PostNuke users, not as a gerenel function.)

But I need more details to get working on this...

Thanks for any help.
Bye,
André

[casNuy]

Andre,

this is caused by the fact that pnCPG stores the passwords unencrypted. Coppermine itself stores the passwords as of version 1.4.1 encrypted unless you follow my directions to revert this. For new users i create a random (not encrypted) password. In principle the users do not need this since they logon thru Postnuke.
Now there are a few options to make it work.
1. I could sent all users their Coppermine password by mail so they can logon directly to Coppermine.
2. They can change their password for Coppermine once they have been logged on to coppermine through Postnuke.
This will not affect the single signon.

I did ask the developers to make the encryption also optional with new installs but so far they have been reluctant to do so.

Cas

[TheGamer1701]

Andre,

this is caused by the fact that pnCPG stores the passwords unencrypted. Coppermine itself stores the passwords as of version 1.4.1 encrypted unless you follow my directions to revert this. For new users i create a random (not encrypted) password. In principle the users do not need this since they logon thru Postnuke.
Now there are a few options to make it work.
1. I could sent all users their Coppermine password by mail so they can logon directly to Coppermine.
2. They can change their password for Coppermine once they have been logged on to coppermine through Postnuke.
This will not affect the single signon.

I did ask the developers to make the encryption also optional with new installs but so far they have been reluctant to do so.

Cas

Hello cas,

that's what I thought.
Of course, I have deactivated the password encryption in cpg, ao this is propably not the problem.
But, It's not an option for me to tell every user to change their password in coppermine.
My site has a few thousand users...

Well,
you must check the password in some way when users go to the Gallery (from PostNuke), maybe we could include this in the login process?
Ohh yeah, and most of my users use the xp_publish wizard and at least 40 percent of them are not using the IE.
So, they can't login through the wizard because it doesn't accept the password...

Question:
Does PostNuke save the password in a cookie or Session variable? Maybe we could store this password when the user visits cpg for the first time?

[Joachim Müller]

storing the password locally (in a cookie) unencrypted is a baaad idea.
The "proper" way to solve this issue, pnCPG shouldn't populate to coppermine database with it's user account data, but should have an actual bridge file that determines the correlation between user fields and hands over user management completely to the app coppermine is being bridged with (in your case postNuke). We decided not to allow unencrypted passwords, as an admin shouldn't be spying (or even be able to spy) on his users. You could say that admin rules, he should be allowed to do everything, but in our opinion this shouldn't be possible, as users tend to use the same login for various pages (although they shouldn't, but you know how things are, with so many usernames and passwords you have to memorize nowadays), so a malevolent admin could abuse a users username and password to try to get access to other systems the user has access to. Having the option to use unencrypted passwords gives the whole coppermine project a bad reputation.
Don't get me wrong: we're fond of pnCPG and appreciate the hard work Cas puts into this project, but we won't change Coppermine's core code for something we consider less secure just as a workaround for making the pnCPG port easier to use. Our main concern is Coppermine (both standalone and bridged as we recommend it), but not pnCPG.

Joachim

[casNuy]

Have to admit that Joachim has a point here although this not keeps admins from spying if they really want. They most likely can access the database directly and see what they want. It is easy to catch passwords if one is looking for this. Every logon process, also the one from Coppermine, can be changed such that the password natively is captured without a user noticing this. Therefore I do not see a major difference.
Nevertheless i do appreciate and respect the developers views. As long as they bring us one of the best galleries and I want to use it combination with Postnuke, I will find a way to make it work.
So there are at least 3 ways to deal with this.
1. For now there is not an issue since we can configure Coppermine not to use encryption. (Most likely this option will disappear in the future)
2. So one thing we can do is to store the (plain) password in the PN database as dynamic user data.(and inform the user)
3. Writing the bridge definately is a good alternative( but I am lacking time for such project at this moment in time).

Now back to the XP problem. In version 3.2, you will have the option to send the password to the user so they can logon outside Postnuke so they should be able to use XP-publish. This functionality can also be used with option 2 so we should be fine for some time.

Cas

[Joachim Müller]

Cas,

thanks for the clarification.

Now back to the XP problem. In version 3.2, you will have the option to send the password to the user so they can logon outside Postnuke so they should be able to use XP-publish. This functionality can also be used with option 2 so we should be fine for some time.

I can see this as an alternative as well. I can understand that it's not an option to send an email to all users if you have many of them, so there's another suggestion: As a users has to download the registry hack at least once before being capable to use XP_Publisher, I'd use the xp_publisher.php output to explain to users what they need to do if they want to use XP_Publisher. Just edit the explanation (either directly in xp_publish.php or the corresponding section in your language file).

Joachim

[casNuy]

Apart from one block, I have version 3.2 now ready. It will work with a Coppermine as is (meaning with encrypted passwords) or with an un-encrypted version.
Now the blocks are also fully templated, so they work again under PostNuke 0.761.
Initial tests seem to indicate all is ok but........
Question for Andre if he is willing and in a position to test this further ?

Cas

[TheGamer1701]

Hello,

of course I am willing to test this.
Well, I have made some changes to your blocks, but I could test them, too. (The remodding is pretty simple. I just added 1 sql and some little html )

but I'm not sure if "I am in the position", what exactly do you mean?
I'm using a rather old PostNuke Version.
Just to make sure, I'm using:
PN 0.726 (phoenix)
CPG 1.4.3
pnCPG 3.1

but I could install a fresh PN and cpg, that's no problem, I got plenty of space left on my server ^^
Just answer here or write me an eMail and I'll do it asap.
I'm on vacation and have lots of time to spent

[casNuy]

apart from the java functions all is done. Will send you the updated version by email.
If your changes are an enhancement, i do not mind adding them. In that case, just send them to me.

As for "in position", was not sure if you had the options for a test site.
In addition, the blocks work with pnRender. I have only tested with pn 0.761

Cas