Has anyone notice how easy it would be to circumnavigate Magic menu's and, if applicable, the rights assign to these by replacing the UserFunctionality with your own 'hacking' version? You could easily replace the, let's say Range function, by a function that let's you call ANY program within your application, even if it is in a higher component, by simple doing a 'Call By Exp' with the program number you enter in your replaced Range functionality. If you add a decimal to the program number, like 12.01, you could call program# 12 in the parent component, of 12.02, for program# 12 in the grandparent component.

I would therefore recommend to NEVER use this ecf as is but to 'copy' this end user functionality into your own application. I say 'copy' but it's more like a rebuild/retype as you can't copy most of it as they are (complicated) functions in the Main Program. This way you can also change the GUI to match your own application. The down side of this is that every time Magic has a new version you need to check if anything was changed in the UserFunctionality. For instance in V3.2 the form size in pixels was introduced which caused the popup screen of the ColumnFilter not to work anymore.

In short: Why aren't all these functions build in like before? Who really needs them to be in an ecf?? I still prefer the old way of doing locate's and range's better on the field directly. MUCH clearer for the end user to use as well. Also this new UserFunctionality doesn't seem to work if you create a temp program with Ctrl+G on a database table.

Perhaps we should start a poll on this? Who wants the old functionality back??

Best regards,

Harry Kleinsmit.

Met vriendelijke groet - With kind regards, Florian Groothuis Analist/programmeur +31 (0)6 21927914

Second that.

Van: main@magicu-l.groups.io [mailto:main@magicu-l.groups.io] Namens harry@...
Verzonden: donderdag 16 februari 2017 13:01
Aan: main@magicu-l.groups.io
Onderwerp: [magicu-l] UserFunctionality is a security breach!

Has anyone notice how easy it would be to circumnavigate Magic menu's and, if applicable, the rights assign to these by replacing the UserFunctionality with your own 'hacking' version? You could easily replace the, let's say Range function, by a function that let's you call ANY program within your application, even if it is in a higher component, by simple doing a 'Call By Exp' with the program number you enter in your replaced Range functionality. If you add a decimal to the program number, like 12.01, you could call program# 12 in the parent component, of 12.02, for program# 12 in the grandparent component.

I would therefore recommend to NEVER use this ecf as is but to 'copy' this end user functionality into your own application. I say 'copy' but it's more like a rebuild/retype as you can't copy most of it as they are (complicated) functions in the Main Program. This way you can also change the GUI to match your own application. The down side of this is that every time Magic has a new version you need to check if anything was changed in the UserFunctionality. For instance in V3.2 the form size in pixels was introduced which caused the popup screen of the ColumnFilter not to work anymore.

In short: Why aren't all these functions build in like before? Who really needs them to be in an ecf?? I still prefer the old way of doing locate's and range's better on the field directly. MUCH clearer for the end user to use as well. Also this new UserFunctionality doesn't seem to work if you create a temp program with Ctrl+G on a database table.

Perhaps we should start a poll on this? Who wants the old functionality back??

Best regards,

Harry Kleinsmit.

Has anyone notice how easy it would be to circumnavigate Magic menu's and, if applicable, the rights assign to these by replacing the UserFunctionality with your own 'hacking' version? You could easily replace the, let's say Range function, by a function that let's you call ANY program within your application, even if it is in a higher component, by simple doing a 'Call By Exp' with the program number you enter in your replaced Range functionality. If you add a decimal to the program number, like 12.01, you could call program# 12 in the parent component, of 12.02, for program# 12 in the grandparent component.

I would therefore recommend to NEVER use this ecf as is but to 'copy' this end user functionality into your own application. I say 'copy' but it's more like a rebuild/retype as you can't copy most of it as they are (complicated) functions in the Main Program. This way you can also change the GUI to match your own application. The down side of this is that every time Magic has a new version you need to check if anything was changed in the UserFunctionality. For instance in V3.2 the form size in pixels was introduced which caused the popup screen of the ColumnFilter not to work anymore.

In short: Why aren't all these functions build in like before? Who really needs them to be in an ecf?? I still prefer the old way of doing locate's and range's better on the field directly. MUCH clearer for the end user to use as well. Also this new UserFunctionality doesn't seem to work if you create a temp program with Ctrl+G on a database table.

Perhaps we should start a poll on this? Who wants the old functionality back??

Best regards,

Harry Kleinsmit.

While in principle I third it, I think a method of “signing” components so that they cannot be hot swapped would be a solution I would support.

Its not JUST UserFunctionality

 

Steven Burrows

 

 

From: main@magicu-l.groups.io [mailto:main@magicu-l.groups.io] On Behalf Of Florian Groothuis
Sent: 16 February 2017 12:04
To: main@magicu-l.groups.io
Subject: Re: [magicu-l] UserFunctionality is a security breach!

 

Second that.

 

Van: main@magicu-l.groups.io [mailto:main@magicu-l.groups.io] Namens harry@...
Verzonden: donderdag 16 februari 2017 13:01
Aan: main@magicu-l.groups.io
Onderwerp: [magicu-l] UserFunctionality is a security breach!

 

Has anyone notice how easy it would be to circumnavigate Magic menu's and, if applicable, the rights assign to these by replacing the UserFunctionality with your own 'hacking' version? You could easily replace the, let's say Range function, by a function that let's you call ANY program within your application, even if it is in a higher component, by simple doing a 'Call By Exp' with the program number you enter in your replaced Range functionality. If you add a decimal to the program number, like 12.01, you could call program# 12 in the parent component, of 12.02, for program# 12 in the grandparent component.

I would therefore recommend to NEVER use this ecf as is but to 'copy' this end user functionality into your own application. I say 'copy' but it's more like a rebuild/retype as you can't copy most of it as they are (complicated) functions in the Main Program. This way you can also change the GUI to match your own application. The down side of this is that every time Magic has a new version you need to check if anything was changed in the UserFunctionality. For instance in V3.2 the form size in pixels was introduced which caused the popup screen of the ColumnFilter not to work anymore.

In short: Why aren't all these functions build in like before? Who really needs them to be in an ecf?? I still prefer the old way of doing locate's and range's better on the field directly. MUCH clearer for the end user to use as well. Also this new UserFunctionality doesn't seem to work if you create a temp program with Ctrl+G on a database table.

Perhaps we should start a poll on this? Who wants the old functionality back??

Best regards,

Harry Kleinsmit.

Met vriendelijke groet - With kind regards, Florian Groothuis Analist/programmeur +31 (0)6 21927914

 

meilink.eu Meilink Beheer Borculo B.V. • Kamerlingh Onnesstraat 1 7271 AZ  Borculo • Nederland • +31 (0)545 253525 KvK 08009803 • Our general terms and conditions apply • Disclaimer

 

I believe it was Keith who suggested a while ago that we could ask for both! And you could choose if you want to use the built-in search/locate... by screen or use the component. Regarding the component,apart from the security concerns which I haven't been able to digest yet I've realized that customizing the component is a double-edged sword and I might easily fall on it in the feature.Done it anyway but still feel a bit uneasy about the whole thing.

Pavel

This email has been checked for viruses by Avast antivirus software. www.avast.com

Has anyone notice how easy it would be to circumnavigate Magic menu's and, if applicable, the rights assign to these by replacing the UserFunctionality with your own 'hacking' version? You could easily replace the, let's say Range function, by a function that let's you call ANY program within your application, even if it is in a higher component, by simple doing a 'Call By Exp' with the program number you enter in your replaced Range functionality. If you add a decimal to the program number, like 12.01, you could call program# 12 in the parent component, of 12.02, for program# 12 in the grandparent component.

I would therefore recommend to NEVER use this ecf as is but to 'copy' this end user functionality into your own application. I say 'copy' but it's more like a rebuild/retype as you can't copy most of it as they are (complicated) functions in the Main Program. This way you can also change the GUI to match your own application. The down side of this is that every time Magic has a new version you need to check if anything was changed in the UserFunctionality. For instance in V3.2 the form size in pixels was introduced which caused the popup screen of the ColumnFilter not to work anymore.

In short: Why aren't all these functions build in like before? Who really needs them to be in an ecf?? I still prefer the old way of doing locate's and range's better on the field directly. MUCH clearer for the end user to use as well. Also this new UserFunctionality doesn't seem to work if you create a temp program with Ctrl+G on a database table.

Perhaps we should start a poll on this? Who wants the old functionality back??

Best regards,

Harry Kleinsmit.