Getting 404 when posting catalog.zip to /episerverapi/commerce/import/catalog from C#

Vote:
 

Hi,  

as a proof of concept I have a clean Alloy Tech CMS extended with Commerce nuget package. I have installed Service API for Commerce nuget package in the CMS part and was able to get the access token when posting to /episerverapi/token

I have followed instructions given here and I keep getting 404 when posting the catalog.zip to the /episerverapi/commerce/import/catalog from C# code. This happens both on localhost (http and https) and on test environment on azure.

Does anyone know if something has changed recently in URL signatures compared to the instructions?

#183781
Oct 23, 2017 13:57
Vote:
 

No, the Url is a part of the public "API" so they can't be changed without a major release - and no we haven't changed that.

Did you try postman to do the posting? How does your request look like? Did you try with some GET APIs? 

#183794
Oct 23, 2017 16:19
Vote:
 

Yes, I did try postman.

GET requests also return 404
for example here is the request for /episerverapi/commerce/catalogs

GET /episerverapi/commerce/catalogs HTTP/1.1
Host: localhost:44358
Authorization: bearer YjEYPG1S1IDRl-XirJAH91T-R4WWaDPq6c9-Dy10oxtKx2CN6y4UhqBC4tPuys-BLoQJ-ihTCqfaLl2nu61XInC0EQXAmpKZvE14ME5fPhIjPntPBsSHU0wBen8YN6lip1iZzUrXuL2xOwyfDYgN5t17QM2nJJhWUxGLfOktE4HD206Zk3HtuQDIHxjtRhlSRSdRUGsPV1UBWvBfdGc_OacFCCMGfADuN0NNPrwwCT69e0-1zY9u4NepVzLvyaGqZQ3i8iaieyXDa9iNBP7VII4mEUxB-B1v2UNVWH4atUhw-6F1GBM5b5xhS6IBADxEA9K3Z0Luj8u93lGCkXP8HWwONmfM6oHN_SwWat0exUQkHlHqxDJN_shM-Ie7c1ppfvq8vr90Bx6J_A4VMbHUQLIORgMOzOYgNtdziVQSTuzaBu8kfUMndSkvrYjzUAlZcLKggLGXH6EE5oBcUxqBBYNNfSFKsJzh0iHLe8Z-8kPSTJqbe0CyOlTwWXPHeHHO
Cache-Control: no-cache
Postman-Token: f3cd363a-c69b-1718-a889-246ddabcfc72

and here is the request for the /episerverapi/commerce/import/catalog

POST /episerverapi/commerce/import/catalog HTTP/1.1
Host: vanillacommerce.azurewebsites.net
Authorization: bearer pLgAViNNgOfK90_9yIP-9_dYK2uc-_uzx-SES6QicJ5ecPmCkV8kKvca82TY4gcfDg0fg_KsFp5bSA4CSvWIi4IeSd6Mxwg4VTaTFaIR6AKvgLddJTuS9jXrMF2UlTq7CWNMXnM9NNGFOoSkfceWEe1RxBDFgGg-9TW3_O0_ucg7OxucqYHPiuvl5JfSo5Zs10SrkS6nhHvQGmb6BMj76GRmj5eYSYF4ckWkuOfioJWHZVtVBtiUbXsfwruFRL8AHNo6v6E7oTRMPP08llk9bR4FaYHJPjSOPVx7zapGdCXPd5rZbULG4d-8CwQFdnX9My4LLH_0TJ3IyFtlQzHkZg8eB8nPwariOjrsbacvvGgdwzzt8uhfeaZrrSTEKJCp5gDPHaw81HYbR1MxY1uu_WT_U36HzBJjvXLfFygzAKZCyM7E7zijeIZKog5V_VHDsPE2hAPxg-YMGhSVSGf40SPzwv0prVP-VgesICN2uwrU1KkeUbiYMP5Pdo1rXBjJ
Content-Type: multipart/form-data; boundary=----WebKitFormBoundary7MA4YWxkTrZu0gW
Cache-Control: no-cache
Postman-Token: 898fb270-2e33-38d4-2ee1-7241494167a5

------WebKitFormBoundary7MA4YWxkTrZu0gW
Content-Disposition: form-data; name=""; filename="catalog.zip"
Content-Type: application/x-zip-compressed


------WebKitFormBoundary7MA4YWxkTrZu0gW--


Implementation of the Configuration(IAppBuilder app) is like this

public void Configuration(IAppBuilder app)
        {
            app.AddCmsAspNetIdentity<ApplicationUser>();

            app.UseAdministratorRegistrationPage(() => HttpContext.Current.Request.IsLocal);

            app.UseCookieAuthentication(new CookieAuthenticationOptions
            {
                AuthenticationType = DefaultAuthenticationTypes.ApplicationCookie,
                LoginPath = new PathString(Global.LoginPath),
                Provider = new CookieAuthenticationProvider
                {
                    OnValidateIdentity = SecurityStampValidator.OnValidateIdentity<ApplicationUserManager<ApplicationUser>, ApplicationUser>(
                        validateInterval: TimeSpan.FromMinutes(30),
                        regenerateIdentity: (manager, user) => manager.GenerateUserIdentityAsync(user))
                }
            });

            app.UseServiceApiIdentityTokenAuthorization<ApplicationUserManager<ApplicationUser>, ApplicationUser>();
        }


I imagine now that something is not implemented right but what confuses me is the fact that I could get the token from the GET request to /episerverapi/token

#183885
Oct 24, 2017 9:39
Vote:
 

Nice job Goran - this is a kind of question that I'd want to see more on World - you spent time investigating the problem, and you express it in a way that easier for us (or me at least) to understand. 

I would assume that you have this in your appSettings episerver:serviceapi:maphttpattributeroutes to false?

#183910
Oct 24, 2017 12:08
Vote:
 

Yes. 

Both that setting and

episerver:serviceapi:requiressl

are set to false.

When doing everything from the beginning I was getting YSOD in case that setting was not in place. Just now, when trying to replicate YSOD by removing that specific setting, it passed without a glitch, so I gave it another go in the Postman. This time I got a 401 error 'User is not authorized for this request'.

Moreover, when tried to implement this on the latest Quicksilver solution installed from GIT I kept getting invalid_grant event when accessing the token URL. I didn't have time to investigate more on the implementation of Quicksilver but I found out that when creating CMS admin user in vanilla implementation I can log into CMS as admin and can get a nice token using those credentials, but when creating a new CMS admin in Quicksilver (no matter if username was in a form of user@domain.com or just username) due to redirection to Login page I could use only username that was in a form of email address but in any case I couldn't login as admin into CMS. This causes, in my opinion, that invalid_grant response when trying to get the token with those credentials.

This is what I need to solve next after I sort out 404 in the question.

#183914
Oct 24, 2017 12:36
Vote:
 

Unless if you are calling config.MapHttpAttributeRoutes(); yourself, then you should not set that to false. I think it returns 404 because the route attributes were not properly mapped

#183919
Oct 24, 2017 14:02
Vote:
 

Looks like it. 401 means that the user was not authorized as I wrote in my previous answer. 

Which user group should user belong to in order to get acceptable token? If it's related to user groups at all. Both test users that I created belong to WebAdmins group.

#183923
Oct 24, 2017 15:06
Vote:
 

Go to admin mode, Config / Permissions to Functions.  Find the Read Access and Write Access for Serviceapi and update to include WebAdmins role.

#183940
Oct 24, 2017 19:56
Vote:
 
<p>Mark thank you. Here is an update. When following 'the path from the scratch' nuget packages add only read/write access rights to Administrators group in the table&nbsp;tblUserPermission.&nbsp;Even <a href="https://world.episerver.com/documentation/developer-guides/Episerver-Service-API/installation-and-configuration/">here</a> it says you need to check it up in the step 9. Yet the only existing group (from scratch) that user can be placed into is WebAdmins.&nbsp;</p> <p>So besides your solution developer can&nbsp;manually create Administrators group in the admin mode and place user into that group and that solves 401.</p>
#183969
Oct 25, 2017 9:27
This topic was created over six months ago and has been resolved. If you have a similar question, please create a new topic and refer to this one.
* You are NOT allowed to include any hyperlinks in the post because your account hasn't associated to your company. User profile should be updated.