merchdb.dat pwd encryption and independent .mvc scripts

[BigDummy]

We have a number of independent .mvc scripts that we use to connect our business system to our online store. These were written prior to the API being available, and work just fine with an unencrypted merchantdb.dat file. However, with the recent update, there is a forced encryption of the password field in merchantdb.dat. These independent scripts are run through a direct call from our local system, and not through any process initiated within Miva. The standard <MvOpenView Name="Merchant"...> doesn't work because there isn't the necessary overhead resources available (I assume). I expect that the basic decryption functions referenced in the dbapi_public.mv won't help either for the same reason.

Aside from storing the unencrypted db password in a secondary location for these scripts, or completely re-writing them for the API, or in another programming language, is there a reasonable way to decrypt the soon to be encrypted password field? Or perhaps to "connect" to Miva in these independent scripts to gain the additional resources needed?

[dcarver]

Unfortunately there isn't going to be any other way. You'd need to tie into Miva Merchant to get this working. Your best bet is using the API if possible. We have a number of libraries in different languages that make the API easy to use (again if possible for your use case).

[ILoveHostasaurus]

Just wanted to add to this that it is strongly recommended to move to the API as soon as possible. Interacting with the store database directly is not secure, not compatible with PCI, and will ultimately become impossible. We do not provision customers in a manner where this is possible any longer, for those reasons along with it often creating major issues with customer support either because a change we make to our software breaks something talking to the database, or a direct database change made outside the software results in consequences that are extremely difficult to unravel. Future iterations of the software may not even use the relational database configuration currently in place.

The API ensures a consistent interface across versions and is independent of the underlying architecture.

[BigDummy]

Thank you both for the comments. The majority of what we do is read from the database. Any edits are very limited and targeted. I have a lot of experience working with databases, and understand very well the risks. Hence why we limit what we do to just the bare necessity. Of course, there was no other way when all of our code was written.

I expected that the answers I received would be focused on the API. However, shifting to that platform will be a longer term project. This is aways the challenge when one writes software to accomplish things that then later are released as part of the standard codebase. By the time the features are released, what works is left alone since it works, until there is a need to work on it. Looks like I have some studying to do.

[BigDummy]

I have only been able to spend a few hours reviewing documentation on how to externally pull/push data with the JSON API. From what I have seen so far, pulling order data, posting shipment info, and updating inventory values shouldn't be too bad. But is there a way to do database table updates for non Miva tables in our database? We maintain a number of our own tables with detailed product information, and occasionally update a single product vs. doing an entire site update. At the moment, I'm not seeing a way to interact with our non-Miva tables. Is there a way? You are right that migrating to the API and a supported method is preferred, but I haven't so far found a way that certain aspects of what we are doing are possible. Any tips would be appreciated.

[ILoveHostasaurus]

There is not. It's not intended for data manipulation that is not via a pre-defined function. The function call ensures first that the data is valid for the intended usage, but also allows our software to have the underlying database schema changed without impact, where code that's specific to a given type of storage, such as a particular relational database, would break.

For your use case, custom tables would present a risk, because we may make a departure from what you currently know as the underlying DBMS, and that would likely break your customization either way. If that data is best kept in a relational database, I'd recommend a separate database from the normal one the store uses, and then your code in the store that accesses this data could MvOPEN that database instead; basically almost the same code but with your own database, which would not be at risk of change.

[BigDummy]

I presumed as much. I understand the purpose to have a layer between. And yes, the changes to the code would be minimal. All of this was set up 15 years ago, so things were a bit different. And I agree that at this point separating them is the best option. Though, we are still on MMUI, and migrating out of that is a higher priority. Unless you are aware of a potential shift out of a relational database structure at some approaching timeframe? Otherwise, I will assume that such a move is simply planning for the possibility/eventuality that something better comes along at some point.

[ILoveHostasaurus]

I would definitely recommend the move off MMUI as a priority; endless newer features would become accessible by doing so, so you'd probably realize far greater value from the software.