I have…
- [x] Checked the logs and have uploaded a log file and provided a link because I found something suspicious there. Please do not post the log file in the topic because very often something important is missing.
I’m submitting a…
- [ ] Regression (a behavior that stopped working in a new release)
- [x] Bug report
- [ ] Performance issue
- [ ] Documentation issue or request
Current behavior
Hello,
We are unable to access some of our apps - see:
Once I select the app nothing happens, opening in a new window redirects back to
cloud.squidex.io (and fails).
The request to https://cloud.squidex.io//api/apps/901-1324735868/clients returns
{
"type": "https://tools.ietf.org/html/rfc7231#section-6.5.4",
"title": "Not Found",
"status": 404,
"traceId": "00-ff1f324ea248684a92d5913e6677d9b7-841df2b34568a145-00"
}
Expected behavior
It should open the app and list the clients in the API
Minimal reproduction of the problem
?
Environment
- [ ] Self hosted with docker
- [ ] Self hosted with IIS
- [ ] Self hosted with other version
- [x] Cloud version
Version: [VERSION]
Browser:
- [ ] Chrome (desktop)
- [ ] Chrome (Android)
- [ ] Chrome (iOS)
- [ ] Firefox
- [ ] Safari (desktop)
- [ ] Safari (iOS)
- [ ] IE
- [ ] Edge
Others:
Account ASAP-Ops
Why is there a double slash in your URL?
I can access and use all my apps, so I cannot reproduce it. have you tried to logout and login again?
oh yeah sorry the double slash is just a copy-paste issue, we can ignore the API call for now but we are unable to access these apps even after logging out and in again. They have been created the same as other apps so there is no reason why they shouldnt load. To give a little more insight the network call to https://cloud.squidex.io/api/apps/901-1324482851/settings returns
{“type”:“https://tools.ietf.org/html/rfc7231#section-6.5.4",“title”:"Not Found”,“status”:404,“traceId”:“00-4fa9532972e99349a1b484543879c513-bcf77a40de3bf541-00”}
If the app is not found why is it showing up in the panel?
I can access the app as an admin but it has no contributors, I don’t know how this has happened.
I just checked the DB and this app has been created by a client. So you have add yourself as a contributor to the app. Otherwise you will not see it in the dashboard.
strange as literally nothing changed on our end and this used to work. I will continue to investigate but i would appreciate it if you could let us know if there have been any updates to production that may have caused this. The 404 result from API call is affecting our CI pipeline while inability to access the app from the UI is also causing us a lot of headache.
I was not aware that this worked before but I will have a look.
1 Like
Do you have the name of another app that you created before with a user client?
Every app visible in the print screen attached was created by the same client
I know the issue know. When I moved to a new authentication system there was a small change, which was causing issues identifying users. Therefore when a user client was used the bearer token created for this client was not identified as a user and therefore the user was not added as contributor. If you add the contributor using the client it should work.
right, thanks for letting us know. So is it a breaking change? i take it you are not planning to roll that back?
I will provide a fix, but It will not solve the problem. What you have to do is to add your user as a contributor to the app using the API.
sure, could you help me find the API query that would enable me to do that?
and just to follow up on that - we would normally create the app programmatically then promote the client to owner role via /api/apps/{appName}/clients/{clientId} but in order to obtain the clientId we would first query this endpoint /api/apps/{appName}/clients to get the default client credentials. This call obviously no longer works so could you tell us if there is any other way to create an app and then promote the client without quering the second endpoint first?
You are right. I guess I have to send you all client secrets. Can you send me a list of app names (or Ids if you have them) via PM? I will send you the client secrets then.
thats fine, i think you missed my point. Basically what we want to do is to create an app programmatically (through the script in our CI) and then attach the contributor since its necessary now.
As far as I understand previously once the app was created a default client would be created whose details we would then fetch in order to perform other operations inside the app (such as syncing the schema and data). This is no longer possible as the main user (the one that creates the app) can no longer get the default client ID and secret.
Is there a better way to handle this? maybe im missing something?
No, it is just a bug. If you send me the app ids I can lookup all client ids and sent them to you.
appreciate it Sebastian, however I dont think this is going to solve anything for us. We create new app IDs all the time - as I said its in our CI pipeline and every time a new PR is raised we create a new environment with a new, dedicated app inside the account I provided in the first post.
If it is indeed a bug would you be able to provide an approximate date of when you expect it to be fixed? and after the fix will we be able to access the list of clients as normal through the /api/apps/{appName}/clients endpoint?
It will be fixed soon. But the other question is: Why do you create so many apps? I know that this app model is a weakness for the cloud because you can get a lof of api calls for free, but it is not supposed to work like that.
Thanks for letting me know.
We create an app each time a PR is raised and delete them once they are closed, as I mentioned earlier it is part of our CI. We do not need make to many calls, in fact, we make very few calls, so its not a way to get around the pricing model.
We were unaware of any limitations that may be incurred, if there are any?
