Loaded project https://github.com/realm/my-first-realm-app in Visual Studio (C#), and running into problems. First, changed GetInstanceAsync to GetInstance to fix crash on init. Second, user is not persisted as login screen keeps asking for credentials, even though user as been confirmed via email. Keep in mind that I haven't made any changes to example other than switching to GetInstance method, and replacing AuthUrl with my realm address in the Constant file.
How do I make this work? Thank you
Related
I use Firebase Remote configuration to control my app features per user segment and so I apply conditions on remote configuration parameter based on some user properties.
The issue is that some of these user properties could be changed when the app user make some actions that change his/her segment (like user was free user and becomes a paid users) and in this case, Remote configuration doesn't fetch the new values so the user sees wrong data in the current app session (sees data related to his previous segment not the new one) and will not see the right data until he/she closes the app and opens it again.
-Are there any solution to force Remote Configuration to update the cached value?
-Is it right to use Remote Configuration in these case or we have to move to another solution like RTDB?
You can trigger Firebase reload by sending silent FCM message either to devices with specific property value or to all devices. Naturally you need to implement handling for the notification and reload triggering. This page describes the implementation very well.
I can successfully create an update on projects but it seems that I cannot overwrite the thread creator by ownerID.
URL sample:
https://workfronturl/attask/api/note?updates={"noteText":"test","noteObjCode":"PROJ","objID"="projectid", "ownerID":"ownerIDxxxxafda"}&method=POST
Can the ownerID be forced to another user?
If I understand correctly, you want to make an update on behalf of a user. We do this all the time as we have a system that translates updates from another system to Workfront. If this does solve your problem, please be sure to write to Workfront and tell them that they need to leave this functionality in the API in the future. I have confirmed with them that this wasn't supposed to work this way.
So, with regards to solving the problem, you need to do the following:
Login as the user who you want to make an update on behalf of. You can do this without having the users password if you have an API key. Just run the login command as you normally would, but instead of passing in a password, send the username and apiKey.
This will return a sessionID. Use the session ID to authenticate when making your update.
If your system is caching credentials, don't forget to log out or all future updates, changes, whatever, will try to use that session ID.
If you are using Python, we built a function into the workfrontapi_plus (only Python3.x) python library to support exactly this called make_update_as_user. As a note, I haven't managed to publish the documentation for this yet, but the doc strings are there and fully filled out with instructions.
I'm building an installed application that will have features requiring the Google Drive REST API using Qt and C++. I understand Qt is now releasing new libraries to support OAuth flows but let's assume I'm a student and learning to use OAuth at this layer is a requirement for this project.
In my application, I have a working OAuth flow for installed applications that ends with an Access Token and Refresh Token being stored using QSettings (I'm open to input on whether this is a disastrously bad idea too). The application requires no authentication/login for its own sake/data, but it does need authentication to Google for calling API's using an Access Token. This application has no associated web backend being hosted; its simple and should be deployable completely locally (I've written and included a simple TCP server that will receive the authorization redirect_uri and will run and close when called from within the application).
As such, I'm curious about the best way to make sure that, when a user opens my application and wants to use the Google Drive features, they are appropriately authenticated on Google's end. Say, if I maintain an access token in the registry, and this access token is granted per-user/per-application basis (right?), then how can I make sure only the user the token belongs to is able to make calls to the API with it?
Here's my understanding and approach; feel free to correct me or educate me if I've got the wrong interpretation.
If an Access Token is found, perform the following:
Open a browser page to a Google login domain and have the user authenticate there (this could prohibit a user from being able to use a cached login session that would have access to a token they otherwise shouldn't have access to)
If user has correctly authenticated with a Google account, return control to the application and make a test call to an API using the stored token.
If the call fails (responds with an invalid_credentials) I should be able to be sure its because the access token has expired and the application will go through the flow to renew an Access Token from a Refresh Token.
If no Access Token is initially found:
Start a normal OAuth installed application flow
Get the tokens and store them so that when the user opens the application next time the former procedure is used
My issue then is the first two steps if the Access Token is found. Nominally this could be done by the typical OAuth flow but it appears that when using a localhost as the redirect uri, Google will always prompt for consent, regardless of settings for prompt and access_type authorization query parameters.
What can be done to accomplish these first two steps in a way that my application can control (i.e. not a solution that relies on a backend server being hosted somewhere)?
If this question is too open-ended for SO requirements I can make some more restrictions/assumptions to limit the problem domain but I'd rather not do that yet in case I unknowingly rope off a good viable solution.
Thanks for reading! Sorry if its a verbose; I wanted to ensure my problem domain was fully fleshed out!
If you are using an installed application, I wouldn't recommend using or storing refresh tokens. Storing refresh tokens on the client side means that if an intruder gains access to the client's application, they have infinite access to the user's application without ever having to enter the user's credentials. If you do insist on having a refresh token, ensure you follow the Google's installed app flow, with the code_verifier parameter included in your requests.
If the access token is found, you should try to verify it, and if verified then use it at the google api, otherwise force the user to login again (or refresh it if you chose to still use refresh tokens).
If no access token is found, your flow sounds fine.
A few notes on loggin in with Google:
Google will only return a refresh token if you specify access_type=offline in your auth request.
Google will only return a refresh token on the user's first authorization request, unless you always specify prompt=consent in your query params.
In my experience, when leaving out the prompt query param, the user is not prompted for their consent again. If they are logged in to google, you will get a new access token, but no refresh token, unless you have prompt=consent.
I think the idea is you use prompt=consent if you have no record of the user ever using your application. Otherwise if they have used it before, you may prefer to use prompt=select_account to allow the user to select which account he wants to use in case he has more then one, or you can just use prompt=none.
This is just my understanding of it all.
My approach I ended up using was just to deploy with an SQLite db that will be stored in the AppData roaming directory. The db schema includes a field for the user's Name (from the OpenID IDToken field if it exists), the user's picture URL (again from IDToken if it exists), the refresh and access token strings (will be stored as encrypted strings when I get around to it), the user's UID/sub string, and a field for a user name and password.
These latter two fields are authentication fields for within my own application, which, again, I wanted to avoid but it seems impossible to do so. So the user will be prompted to enter a username and password into a form, and these credentials will be checked against the existing SQLite db file mentioned previously.
If they exist and are correct, the user gets logged in and will have access to their respective access and refresh token.
If the user has forgotten their password, they'll be asked for reconsent (going through the installed app flow again), and whatever password they provided during initial login will be used as the reset password. It is considered, for my purposes, that logging into Google for the installed app flow is proof enough that the user account belongs to them and they should have authorization to reset the password.
If the user is a new user and doesn't have a record in the local SQLite db file, then they can also click a button to "Create New Account" - which effectively goes through the authorization flow as well but this time a whole new record is posted to the SQLite db with the appropriate fields filled.
There's still more optimization that could be done but at least I am getting closer to the level of security and control of access to Google user accounts that I want.
I'm not marking this as an answer because I feel like this solution is still not desired and that there should be an easier way. So if someone has evidence or experience of providing an equivalent level of authentication control without needing to maintain a local user account database then I would be more than happy to mark such a method as the solution!
Thanks again!
I can’t seem to be able to force the user consent dialog to appear.
The first time user logs in, the consent dialog properly comes up.
However, after we change the app permissions or the user manually removes the app consent (from portal.office.com/myapps) then we can no longer cause the consent dialog to re appear.
Details:
UWP Windows 10 native client connecting to WebApp (ASP.NET) which calls downstream WebApi (O365) using the “on-behalf” oath2 pattern (using latest 3+ ADAL libraries)
Single tenant WebApp (no special admin perms)
After changing WebApp permissions (eg adding more o365 apis) or the user removing the WebApp consent, the WebApp’s AcquireToken returns AADSTS65001
Using wtr.Properties.add(“prompt”, “consent”) in the UWP client app does not cause consent dialog to re-appear
Re-cycling WebApp (to clear the built-in AAD token cache – it doesn’t use its own token cache) or clearing the client’s token cache (by login out) does not help
What is the proper way to having the user re-consent?
When I create a firebase reference and take a snapshot of that reference while authenticated through firebase authentication then I log out, that data remains.
Requirements:
Page cannot be reloaded or force reloaded after logout
Cannot Clear Firebase Session or all data will need to be reloaded
Must clear only the data that was accessable to the user and not to the public
Must also reload data that is owned or is in the same group as the non-escalated or guest user after the other user has logged out.
I am considering creating objects that wrap my references that will supply a user group and other permissions property as is commonly seen on linux. This will allow me to use the current user object that provides group and user details as a base for deactivating or clearing local data.
Is there a standard way of doing this?
Am I making more work of this than is needed?
I will be hardcoding the knowledge of what groups have permission on the clientside to be replaced later with metadata provided by firebase. I plan to eventually keep track of all references available to a specific user under the user id as well as keep track of the references available publicly and as well again keep track of references available to specific groups where the highest permissions takes priority.
Step one I am taking is creating a way to manage the references clientside and build in checks for authentication change and then utilizing the user details provided in the current auth apply needed changes with authenitication change kicks off. Is it easier to just initiate another call to the server for that snapshot, will that snapshot change if it is no longer authorized?
You control your own app and the prefs based snapshot (or wherever else you save the data) is under your app control as well. Assuming that whatever local storage is protected to your app only (whether natively by Android OS such as private prefs or otherwise), you can simply save the local cache under the user id of the currently authenticated user. So your app can check if the authenticated user matches that user id of the cache and if it does not, then access is denied. In fact, the local cache should be keyed minimally by the logged-in user so you get that kind of check for free (basically the snapshot data won't be found).