I have a Rest API resource setup with custom auth to Azure GraphQL using client credentials flow.
I don't seem to have any issues with it when testing on the desktop or in Edit mode.
I have two users - one is a full admin, and one only has read/use access on certain resources and apps. I couldn't seem to get the resource to Authorize on the mobile app when logged in as the read only user.
I made sure that in the settings the user had full access to use the resource, and the app itself set to 'edit'. No matter what combinations I tried, reloading the app etc. I could not seem to get the Authorization to go through. I finally tried setting the secondary user to 'own' on the permissions page - and now all seems good?
Not sure what 'own' vs 'use/edit' means here. Is this normal? I guess another wrench to throw in is that when testing this from some other users devices before making this change it WAS authenticated - but seemed unreliable. Am I just missing something here?
@msd5079 hard to tell exactly what's going on here. Can you share (1) screens of how your GraphQL Custom Auth is set up, and (2) a screen recording of what it looks like when the read-only user attempts to use the app on mobile? (Feel free to censor any proprietary info)
Got it, thanks for sharing. We actually currently only officially support OAuth2 resource authentication in the Retool Mobile native client.
However, coincidentally, I shipped a prototype of custom auth this week that I can enable for you if you email me your Retool org name (my email is braden AT retool dot com). Enabling should unblock you here!
So the resource i have setup now - that is working - is REST API with custom Auth using client credentials flow, are you saying that it should be not functioning at all?
Either way id be happy to test out the new prototype - ill send over my org shortly!
I have the exact the same problem in Retool mobile app for custom api authentication. It's works ok in web but not in mobile. Could you help me to fix this please?
Retool Mobile should support all the same resource auth that regular Retool does now. Can you share more about what you're trying to do, how you expect it to work and at what point it stops working?
When I open my app on Retool mobile, the screen appears asking me to log in to use the API resource. However, when I tap the authenticate button, the modal to enter the username and password disappears in less than a second without allowing me to take action. This happens on both iOS and Android. If I try as a PWA, it doesn't open any modal at all. I also don't have a way to automatically trigger the login modal like there is in web apps.
In mobile app, sometimes shows me this authenticate page but when i try to to autenticate the input modal for email and password disappears in less than one minute (iOS and Android). I cant trigger this page manually so i dont know what do i have to do.
Hi @Gianluca_Chiesa_Pastor it looks like the video attachment might not be compatible with the forum post
Did you try emailing the video to Braden at his email which I posted in my comment above? That should definitely work, the forum has some limitations of video formats and I find it hard to do anything other than a screenshot
For your ticket which you created on may 10th, if you can add that link to the email and/or your response here it would make it much easier for us to find it and help!
Hey Gianluca, I explored the behavior a bit with a simple repro and am able to get the form to stay visible for long enough to type in it properly. However I also see the behavior you're seeing somewhat. I think our approach to custom auth may be confusing -- it seems like when we pop up the auth modal, we also trigger your resource, and if we get a 200 back from the endpoint we close the modal immediately because we assume you're authenticated properly. So your "time-based expiration" config is probably not doing exactly what you want to.
I think in order for this all to work properly together you need to (1) have an auth workflow defined, (2) have an appropriate auth trigger, and (3) most importantly your main REST endpoint should be returning 403s when you need the user to re-auth. The auth trigger is effectively ignored if the main endpoint returns a 200.
Let me know if that's what's going on here. It seems like the interaction between auth triggers and main endpoint response codes can create a LOT of edge cases so it's possible this isn't your exact issue.
-- Braden
I've attached a screenshot of my test config; you can see I'm forcing every endpoint to return a 403.
