Pass MWS keys without config file

[haffoudhi]

Is this possible ?
I need to pass different MWS keys every time, and one config file is not the correct way.
Is it possible to pass the keys directly without config files?

[Peardian]

I was under the impression that MWS Auth tokens were created once, at the same time as the Seller ID. Could you elaborate on your setup a bit? I need to know if this is an edge case or not before I decide on what to do about it.

[haffoudhi]

I m building an application for multiple sellers, each seller provides his own MWS auth token and seller ID. The app must do multiple reports at the same time for multiple sellers, using one config file is not an option here. The solution i m using is creating a different config file for each user and passing path to config file in every call to "phpAmazonMWS". I would prefer a more simple way, where i can introduce to api keys dynamically in every call, e,g new AmazonProductList($seller_id, $marketplace_id, $key_id, $secret_key..) not using a config file.

[Peardian]

That sounds like something worth supporting. I don't know how long it will be before I can work on it, but look into adding this feature when I can. Thank you for bringing it up.

[ahmettok]

I think it is a great feature to add, I also use the library for multiple users and I generate a new config file, every time I run the application, Queue the requests so that only 1 job is done.

[morphers82]

There are tons of apps out there that access MWS on behalf of their users, this is definately not an edge case, in fact i think accessing mws for just a single seller is probably more of an edge case than accessing using a Developer Accounts Key/SecretKey plus the user's merchantId and a MWSAuthToken that has been issued by Amazon to be used by the developer account to access the MWS API on behalf of the merchant. Thanks!

[stevechilds]

I would echo this. I'm developing a integration using Symfony and its really not ideal to have to configure a php script within the vendors folder OR as I've done, create another PHP script in app/config and pass it into every constructor in the library when they're called.

The easiest solution would be to change it to accepting an array in the same parameter and doing a simple is_array() check, if it is, grab them, from there, if not use the existing code, then it doesn't introduce a BC break.

Edit: Actually is made worse by the fact the config param changes position with various constructor calls. I had planned to have a factory approach to generating them, this makes that harder as a now need to account for the fact that different constructors have them in different argument positions. :/

[Peardian]

My plan was to allow the first parameter, normally the store name, to be substituted for the array. After all, why would you need to give the store name if you're passing exactly the requirements you need? Unfortunately, I cannot work on it right now.

[stevechilds]

I've started to look into this, but oh hell! You've used the config file to set the store variable locally within each method it gets called in! :/ OMG, I can see why its a nightmare now. Sorry, but that's really, really awful design.

Ok, I've just searched and "include($this->config)" may only be in just under 30 places. What I would suggest (and I don't mind doing this, as long as the library does what we need it to do), is changing it so that the stores are read in and saved in the core class when its constructed, so that you don't need to include the config file each time you want to access them. You can pass them as an array in the store param as you suggest, these then get saved into the AmazonCore class.

Then wherever in the code include($this->config) is called, the method is changed to get the stores from the class property rather than the $store variable within the scope of the method.

The revised existing methods would still work with the current config file method as that file would be read in once in the AmazonCore constructor and saved into the object in the same way.

Thus accessing the data is the same irrespective of whether the config data is file based or array based.

Out of interest, why weren't the stores persisted into the Core object, as you do for some of the other settings?

[Peardian]

I won't defend my code on that point. After all, I wrote it 3-4 years ago as my first library.

I think that persisting the config data to the object would be a good idea, though I am not sure how exactly that could be done without changing the structure of the config file. After all, the config file contains several variables in addition to the store array, and all of that information needs to be passed to any created child objects. Those variables might need to be added to the store array anyway for the "config without file" idea to work. Perhaps that is why I designed it this way, so that only a single file path needs to be handed down.

Maybe there could be a configuration object? It could handle all of the loading/storing of config information and would simplify the passing of configuration to other classes. Just a thought that came to me while reading your message.

Regardless of how the store settings are saved, I think only the relevant store's array should be kept rather than all of them. I want to keep as little sensitive information stored in the object as necessary.

[stevechilds]

@Peardian I appreciate the code is old, I wrote some really bad code in the early days! We'll sort it though :)

I was thinking along the same lines and have created a configuration class/object which either takes an array or a file to keep backward compatibility. The core classes then refer to the config object rather than including the file all the time.

I've got it up and running with the simple test (getServerStatus) I had, now I just need to address the 221 test failures!

I've moved the logFile validation into the config class too, so I also solved the LogFile creation issue at the same time.

I'll add some new test cases too for the new functionality :)

I am trying to keep breaking changes to a minimum, so far there shouldn't be any! (fingers crossed)

[stevechilds]

Done :) All tests pass! I'll do a bit more testing, make sure I haven't missed anything and I'll commit the changes for you to review later today.