-
New Commercial Services Section
We have now opened a commercial services section here on the forum for registered users. If you have a Fabrik project that you wish to have someone work on for you, post it under Help Wanted. If you are an application developer and wish to earn some money helping others, post your details under Fabrik Application Developers.
Both of these are unmoderated. It will be up to both parties to work out the details and come to an agreement.
-
Joomla 5.1
For running J!5.1 you must https://fabrikar.com/forums/index.php?wiki/update-from-github/ or include the new file manually https://fabrikar.com/forums/index.php?threads/joomla-5-1-and-fabrik-cannot-find-files-error.54473/post-285151 See also Announcements
Encrypt connection passwords
- Thread starter Barcellos
- Start date
cheesegrits
Support Gopher
I'm not sure what you are referring to?
-- hugh
-- hugh
Barcellos
Ana Barcellos
Okay... I was trying to encrypt the fabrik connection password as Rob suggested in the link I posted above.
Again: https://github.com/Fabrik/fabrik/commit/dcdffe28eff7c3a95a37fed90cee55f90f8950b3
My problem:
Only Superusers should know the database password but all administrators can see it if they go to Fabrik Connections > Site Database and inspect the element "Password" (as you can see attached).
We tried the fixes #445 Encrypt connection passwords (linked) but it didn't work.
We are using Joomla 2.5 and Fabrik 3.0.9.1
Again: https://github.com/Fabrik/fabrik/commit/dcdffe28eff7c3a95a37fed90cee55f90f8950b3
My problem:
Only Superusers should know the database password but all administrators can see it if they go to Fabrik Connections > Site Database and inspect the element "Password" (as you can see attached).
We tried the fixes #445 Encrypt connection passwords (linked) but it didn't work.
We are using Joomla 2.5 and Fabrik 3.0.9.1
Attachments
cheesegrits
Support Gopher
Oh, I didn't notice the link. I need to change the link shading in the forum CSS. That dark grey just isn't noticeable enough for my Old Man Eye Sight, so I didn't realize the word "this" was a link. I'll take a look.
-- hugh
-- hugh
cheesegrits
Support Gopher
OK, so ... that code is for 3.1, and I can see a couple of reasons why it wouldn't work as-is for 3.0. But it works fine in 3.1, so all connections in 3.1 which have been created (or edited and saved) since that commit are encrypted in the database, and on the form.
I'll take a look, see what it would take to get it working in 3.0.
Although to be honest, I'm not entirely sure why we even give that password field a value. AFAICT, we should just leave it blank, and only do anything with it if someone fills it out by hand.
-- hugh
I'll take a look, see what it would take to get it working in 3.0.
Although to be honest, I'm not entirely sure why we even give that password field a value. AFAICT, we should just leave it blank, and only do anything with it if someone fills it out by hand.
-- hugh
cheesegrits
Support Gopher
Hmmm, I don't quite get our logic in there anyway. I so rarely create or change connection details, I hadn't looked at this in a while.
As we don't pre-fill the confirmation, we force you to type the password in anyway. And there's no point in pre-filling with the encrypted password, as we wouldn't know if what came back in the form was the old encrypted password, or a new plain text one ... without dicking around comparing old and new values. And you obviously can't type the encrypted string in the confirmation.
So ... I think better logic would be what I'd expect it to do in the first place, which is:
Don't pre-fill either password field with anything.
On submit, validate and fail if:
1) Password and confirmation don't match.
2) It's a new row (not editing an existing one) and both are empty.
... and if it's an existing row, and both fields are left blank, just remove the password from the field list for the connection row being updated, so it stays the same.
That way when editing a connection, you can just leave both password fields empty, and nothing changes. And there's never anything prefilled in the form, encrypted or not.
Does that sound about right?
-- hugh
As we don't pre-fill the confirmation, we force you to type the password in anyway. And there's no point in pre-filling with the encrypted password, as we wouldn't know if what came back in the form was the old encrypted password, or a new plain text one ... without dicking around comparing old and new values. And you obviously can't type the encrypted string in the confirmation.
So ... I think better logic would be what I'd expect it to do in the first place, which is:
Don't pre-fill either password field with anything.
On submit, validate and fail if:
1) Password and confirmation don't match.
2) It's a new row (not editing an existing one) and both are empty.
... and if it's an existing row, and both fields are left blank, just remove the password from the field list for the connection row being updated, so it stays the same.
That way when editing a connection, you can just leave both password fields empty, and nothing changes. And there's never anything prefilled in the form, encrypted or not.
Does that sound about right?
-- hugh