I have a simple login page that takes some credentials, constructs a BASE64 encoded Authorization header and then sends a GET request with the header to an endpoint. If the request succeeds, it will return some company information and then navigate to the main screen.
The flow is configured like this:
The flow works fine when I run it from the Web preview, but if I run it in the SAP Preview app I get an “Invalid session” response from the endpoint. I have used the debugger to make sure the authorization header is constructed correctly (which it is), but I can’t figure out what else could be failing here.
This is the web preview:
And this is the Android Preview app:
And this is as much as I can see from the debugger:
Does anybody know what could be wrong here?
Thanks and best regards,
If anybody’s curious, I deleted the Android Preview App “Data” and “Cache” and then logged in again. That seems to have done the trick and it’s now working… for the first login.
Subsequent logins to a different company database unfortunately seem to be not considered and I keep getting data from the first login. Seems like a caching issue, since it’s working on the web preview, but not in the Android PreviewApp.
Is there a way to control the caching behavior of the Android app?
Thanks and best regards,
Hmm. This sounds odd to me. What are you using for backend? I don’t see why or how the preview app should cache this response (unless you yourself set it to local storage or similar), but that’s also not my area of expertise
For a full-fledged app however you probably want to persist login somewhat and store an authentication token in local storage, so if there’s a way you can alter your code in a way that you could store the required token to get access to the rest of your data, that would be best, and also more user friendly for your users that they don’t need to log in all the time. Perhaps that would get you around this issue, but it might also not if the backend just won’t allow logging in from the same device before cache is cleared, even after the token expires.
The backend is SAP Business One (specifically the Service Layer, which represents an OData interface). I have not used any local storage.
I have since changed the login procedure to POST to a Login endpoint instead of using BASIC Authorization, and that has taken care of the caching issue. After all, POST requests can rarely be cached.
Authentication tokens are not an option in this case, unfortunately, but the Login request sets a cookie which is stored and resent automatically.
Oh, I should also mention that the switching to a POST Login endpoint broke the Web preview. While it works fine on Android Preview now, the web preview does not seem to reuse the cookie, so subsequent requests are automatically failing.
This is the Login response (cookie has the correct same-site attribute, CORS is configured):
And this is the next request (no cookie included):
I asked about this and at the moment, the flow function does not have
credentials: "include", which is why the cookie is not saved. Instead, it needs to be explicitly included in the request headers. We’re considering an option of choosing to include the cookie, but as that is not available at this moment, it won’t help you right now
We recommend saving the cookie from the header of the login request and storing it in an app variable, so you can use it in further requests in the authentication header.
With OData I haven’t seen the possibility to receive or send any additional headers except the authentication header. Does that possibility exist at all? Any documentation on this topic?
Also, the equivalent behavior of the Android preview app is to include credentials, why wouldn’t that be the same for the web preview? Shouldn’t that be classified as a bug eventually? It makes for some quite inconsistent behavior…
Oh, shoot. That’s definitely a missing feature we need to implement There should be a way to include cookies via headers at least, if not the possibility to automatically include them when possible. I created tickets about that, hopefully it’ll get fixed sooner rather than later.
I’m not sure if this works as a workaround, but so that you wouldn’t be blocked I would suggest trying if you can use plain HTTP request flow functions, as you can include whatever headers there, or if you’re ok going forward with development with the current system until this is fixed, you can try to wait for this fix.