I've been using Netlify for storing 100% of my app (both frontend and backend) for the last three months. So far, so good.
The only problem now is that I need to store a custom property for each user (say, the phone number), and apparently Netlify Identity doesn't support this (only email, name and roles https://www.netlify.com/docs/identity/).
I don't want to change the whole app to migrate to another hosting provider just for this detail (actually, I can't, it's for a client and I just don't have time), because it works great, but at the same time I need it.
Can you think of any workaround to this? The less "hackish", the better, but I understand that I'm going beyond the intended use of Netlify Identity.
So it actually does look like Netlify's GoTrue API has a specific endpoint for updating custom user data. After a user is created, you can update metadata by including it as "data" within an authenticated PUT request to /user.
PUT /user
{
"data" {
"custom_key": "value",
}
}
See https://github.com/netlify/gotrue for more info.
There are dozens of ways to do this, so I'll talk about two generally applicable ways now:
the most "generally capable" one is probably using lambda functions: https://www.netlify.com/docs/functions . This lets you run dynamic code, such as "store to database hosted elsewhere" or "email to our office manager to update a spreadsheet" or even "commit to our closed git repo so it's available in-code" (last one is probably a worst practice, but is possible). You can similarly use a function to read that data back out without exposing API tokens (code example: https://github.com/netlify/code-examples/tree/master/function_examples/token-hider)
you could have the data gathered via a form submission (https://www.netlify.com/docs/form-handling). I'd probably use zapier.com to receive a notification of the form submission (https://www.netlify.com/docs/form-handling/#notifications). Zapier can of course connect to just about anything on the planet :) . Getting the data back out if you want to show it in your UI is a bit more of a challenge, but you could use the above mentioned functions if you need to connect to some private data store to pull it out. Or for an MVP, just not show it, only let people enter/update it ;)
Related
We need to develop an API which takes a CSV file as an input and persists them in database. Using vertical slicing we have split the reuirement into 2 stories
First story has partial implementation with no data validation
Second story completes the usecase by adding all validations.
Sprint-1 has first story and sprint-2 has second. After imlemneting first story in sprint-1 we want to release it to production. However, we dont want to make the API accessible to public which would be big security risk as invalid data could be inserted into database (story1 ignores validation)
What is the best strategy to release story1 at the end of sprint1 while addressing such security concerns?
We tried disbling the access via toggle flag such as ConfigCat. However, we dont want to implment something which is not required for actual implementation
is there really such a risk that in 1 sprint, someone may start using the API? And if you haven't added it to any documentation, how would they know of it's existance?
But let's say it is possible - what about using a feature toggle? When the toggle is activated, the end point spits out null or even a HTTP error code. Then you can enable to feature toggle when you're ready for people to start using the endpoint.
I am developing an identity server 4 dotnet core application so this is as much as a dotnet question than and IDS4 question. One example of state I need to maintain between pages (login, signup etc...) is the returnUrl. The application I'm migrating from used to store it in a session variable but, as I understand, unless I run a persistent session strategy, this won't scale well.
So currently, I'm passing it around as a field in each View Model used by each view so it can be returned. Is this a sound approach? I'll be needing other fields to be passed around as well so I'm wondering whether this is a secure and logical way to do it.
So currently, I'm passing it around as a field in each View Model used by each view so it can be returned. Is this a sound approach?
Yes, how you choose to pass it around is up to you, I choose this same approach. You could use TempData, Sessions or even localStorage as an alternative. I think having it in the models (view models) is a good approach because you are explicitly specifying where you want the return url to exist, otherwise it might persist in context that you wouldn't want.
Now the security question because obviously you might be able to see the return url in the browser address field.
As part of Identity Server 4 setup you specify which return url's you are allowed to redirect back to, so I don't think there is any harm in having the users see the redirect url.
Something to consider is what if the user would share the url to someone else in the middle of the authentication process, would they be able to resume from that part of the process that the initial user has stopped? is this something you want in your app?
If you mean reliably instead of securely, write tests which will provide you with confidence that your code works.
How to refresh the interface after you add a strip of data to the backend database in Vue.js?
I mean, if I add a item data to the database. there are two case for refresh the interface.
refresh the list api to get the page data.
append the added item data to local list.
what is the best way to do this?
I think both the solutions are valid it depends on what kind of write operation we are planning to do. Given that you do all the validations on the front-end which leaves lesser chance for errors on the backend. I do the following based on the use case.
Add/Update the item locally and then based on the response from the server I remove it again in case of an error. This is an optimistic technique used by a lot of websites and worls really well for CRUD kind of operations.
Let's say that your new operating is going to creaate a new user in a 3rd party api. So doing an optimistic thing might not be the best. So what I do is make the request, show a toast/alert that the request is happening, and then use sockets or long polling to get the changes. When the request is finally done show the data. In the meanwhile you can insert a dummy item showing loading.
I'm building an API centric web application.
Our frontend will consume the API and after testing our plan is to release the API to the public.
I'm faced however with problems that in a normal MVC application were pretty straight forward but I can't seem to wrap my head around it in a RESTful way.
Take this example for instance:
A company has multiple office sites which point to a specific address
This address can be shared by multiple sites so Company has a one to many relationship with sites and sites has a many to one relationship with Address
When you update an address I'd like to let the user confirm that for that they either want to update the LOCATION (so all companies that share that location through Site will be updated) or they just made a typo and want to create a new Location
How would I go about this in a RESTful way?
I can do a
I first do a GET if there are other companies using that location
Then I give the user a choice either to do POST (create new location) or do a PUT (update location)
In case of POST also create a new Site linking the new location to the Company.
An other example is if what appears a single form for the user will invoke several different backend entities that have to update.
Any examples or ideas?
In REST, you might thing of the remote service as being the database. If you know how to do it in a generic MVC workflow, for fat-client apps it's the same.
You may want to deal with it on a "try default behavior, and raise attention if not possible" way, or with a "check what's possible and then offer possibilities". It's your app, it's your choice.
Personally, I'd go with a "try default and raise error if edge conditions happen". So in this case, assume (in the client) there is no other company with the same address, and use the corresponding endpoint (PUT). If the server detects a possible conflict, then return some error. The client will then prompt to the user what to do, and use whatever endpoint is chosen (POST or PUT, with a flag that enforces the update)
I'm about to create an application that uses JSON to update its content.
This is how I planned it to work:
When application starts, it checks (with internet connection is available) if the JSON file set on remote server is newer than the one stored localy - if it is then it's downloaded.
Then, the application applies data from that JSON to the content. For example, to the "Contact" information - it applies data like phone numbers etc.
My question is, is it in your opinion, a good technique to update appliactions content?
Does anynone had an experience with building app with this kind of idea?
Best regards,
Zin
Of course you can do this. One thing that may lead to a better user experience would be to ask the user for his permission to download new content (if there is something new).
This is a normal thing to do. I have a phonebook app that does exactly this. On a side note, if you need a network class to handle the web-service interaction, see this SO post. I wrote a custom network class that works with AFNetworking.