Feature request: optional application-wide access token reuse across requests

[filiptorphage-mjuk]

Hi,

We have a use case where it would be useful to allow an application to reuse one FileMaker Data API access token across requests, so that separate incoming PHP requests can share the same FileMaker database session instead of creating a new one each time.

If a command fails because the token is no longer valid, the idea would be to discard it, establish a new session, and retry the command once.

This seems like a potentially useful optional feature for applications that use FMDataAPI through a shared service account and do not require per-request session isolation.

Since a FileMaker Data API access token defines the database session itself, I wanted to ask whether this kind of application-wide token reuse and retry logic would be considered in scope for this repository, or whether you would rather see it implemented as a separate wrapper around FMDataAPI.

In our case, we do not use global fields or scripts. Because of that, the main practical concerns seem to be token expiry and how overlapping requests would behave when sharing the same FileMaker database session, rather than session-scoped field or script behavior.

I’m not proposing a specific implementation here — mainly asking whether this kind of optional functionality feels like a fit for the library.

Thanks.

[msyk]

FMDataAPI can keep the authentication state. The startCommunication() and endCommunication() methods of FMDataAPI class are simple way to do it.

[filiptorphage-mjuk]

Yes — I agree that startCommunication(), endCommunication(), and setAccessToken() provide the building blocks needed to implement this outside FMDataAPI.

The part I was asking about is reuse of a single FileMaker Data API access token across multiple PHP requests/processes.

If startCommunication() is called at the start of each PHP request and endCommunication() at the end, then each request still creates its own Data API session. What I had in mind instead was restoring a cached token with setAccessToken(), attempting the command, and if the token is no longer valid, discarding it, creating a new session, and retrying the command once.

So the idea I was trying to describe was:

1. restore a previously cached access token
2. attempt the command using that token
3. if the token is no longer valid, discard it
4. establish a new Data API session
5. retry the command once

So the question was mainly whether this kind of cross-request token reuse and retry logic is something you would want FMDataAPI to support directly, or whether you would prefer it to live in a separate wrapper around FMDataAPI.

Thanks.

[msyk]

OK, I understand your request, I think... FMDataAPI can keep the credential token but it's just in one session. You're requesting to use the common access token within multiple sessions, also with refresh-able token. I have made the Dropbox library with the similar mechanism. I think I can implement such a feature, but I need a block of time.

[filiptorphage-mjuk]

If it would be useful, I’d be happy to open a PR based on an idea I have in mind. You could then decide whether the approach makes sense and whether any part of it would be a good fit for this repository.

Unrelated question: do you happen to know how the FileMaker Data API handles multiple concurrent requests using the same session? I have not been able to find a definitive answer in the documentation. The only somewhat relevant thing I have found is the validateSession endpoint found here, which indicates whether a session is currently in use, but I cannot find anything explaining what happens if a token is used for a new request while another request with that same token is still running.

[msyk]

If it would be useful, I’d be happy to open a PR based on an idea I have in mind. You could then decide whether the approach makes sense and whether any part of it would be a good fit for this repository.

Thank you very much!! Your PR is quite welcome!

Unrelated question: do you happen to know how the FileMaker Data API handles multiple concurrent requests using the same session? I have not been able to find a definitive answer in the documentation. The only somewhat relevant thing I have found is the validateSession endpoint found here, which indicates whether a session is currently in use, but I cannot find anything explaining what happens if a token is used for a new request while another request with that same token is still running.

I tried to check the performance of FMS19 as like Benchmark Test of Web Technology in FileMaker Server 19. This is Japanese article but everyone can translate anyway. I could parallelly send requests with the same account, but they can't over the license number 3, as far as my license is for developer. Each request has the sequece of login and query and logout. How do you think about the result of my test.

[msyk]

@filiptorphage-mjuk pointed out as follows:

I did point out a flaw of this PR that needed to be fixed (it's currently broken), which is why I changed it to a draft. And there were some things that I would have preferred to have a second look at first.
I guess I'm not used to making PRs to public repos, but I would have assumed a draft PR wasn't completely ready.

• The execute function does not refresh a token correctly when setThrowInException(true), this is because errorCode() not being accurate, and only contain the error code of the previous request (not current). This I was hoping to discuss a solution before merging, as this actively needs a fix.
• i also think a better name than execute could be chosen, as it is essentially just a retry logic of a token expires.
• Internally we have also discussed whether it would make more sense to merge startCommunication() and beginPersistentSession() into just a startCommunication(). The idea here would be to check whether $this->persistentSession is null or not. If it's null (default), then perform the old functionality of startCommunication(), but if it's set, change it's behavior to what beginPersistentSession() currently does. That would have removed the possibility of accidentally running this PR's beginPersistentSession() which could throw a RuntimeException. But whether this would be a better idea we would leave to you in the end (this point)
• We haven't looked into if the PersistentSession class actually provides enough justification to exist, or if it's helpers could be used directly.

[msyk]

I will check them one by one. Please wait for.

[filiptorphage-mjuk]

@msyk i will bring forward my suggestions soon. I'll probably be able to post it on Monday or Tuesday. I apologize for the delay. I would recommend waiting for that one as I've been spending time in improving my whole PR.