I have a case open with Plaid support, but it has not been even touched since opening 12/26, perhaps they are just all on vacation for the last week.
We had use the prior API for a site and wanted to use it for a new site. We found the API has drastically changed since the last time, as year ago, and have everything seeming to work in the sandbox, but for "development" or "production" cannot get the TD Business Direct to link up and produce the needed access_token so we can pull transactions into our application.
So I am hopeful with the post I may get some help knowing what the error of "the login details of this item have changed (credentials, MFA, or required user action) and a user login is required to update this information. use Link's update mode to restore the item to a good state" really means. The Plaid Link flow seems to accept the initial credentials and the responses to MFA, but after the second question is answered gives the error and we are not able to link the account.
We see a 400 status when it tries to post out after the second MFA question is answered and shows:
{
"display_message": null,
"error_code": "ITEM_LOGIN_REQUIRED",
"error_message": "the login details of this item have changed (credentials, MFA, or required user action) and a user login is required to update this information. use Link's update mode to restore the item to a good state",
"error_type": "ITEM_ERROR",
"request_id": "request_id_here"
}
Other details when we exit that may be helpful:
{"institution":{"name":"TD Bank - Business Direct","institution_id":"ins_107836"},"request_id":"request_id_here","link_session_id":"session_id_here","status":"requires_questions"}
From just reading the message would seem we may not have entered the right credentials, but we can login to the bank site just fine, so they are right and the account is not locked out.
When I've faced the similar issue, the reason was in changed user's details. Every time some details changed, you'll need to re-link user's bank account with plaid in update mode.
Exception with "error_code": "ITEM_LOGIN_REQUIRED" will help you detect such cases and handle them appropriately.
They have more info in their docs: https://plaid.com/docs/link/update-mode/
Link update should work fine. If you are facing some issues further, then create a support ticket to plaid and let them know that request id, bank_id and what type of error you are getting.
Sometimes the issue is on their side. There are quite slow in responding but you will get reply within 2 days and if there is some fix, they would ask you to test it after the fix is pushed on their side.
Related
I am developing an ASP.NET Core web application with user management functionalities. My question is about the email address changing algorithm. Almost every web app I saw before have the following flow:
User authorized
User requested an email address change
User received a message on the new mailbox with the confirmation link
User clicks the link and the email address updates
But I think, this algorithm might be a bit insecure and that is what I want to discuss here.
How about this flow:
User authorized
User requested an email address change
User received a message on the old mailbox with the confirmation link
User received a message on the new mailbox with the second confirmation link
User clicks the link and the email address updates
With this additional step in the middle of the algorithm, things may be much better from the security perspective, but would it be too complex or not? How do you think what algorithm I should implement? And what would you prefer if you will be in my shoes?
The second options might sound great, and it's not too much headache to implement too. But I'll stick with the first approach due to some reason:
Common work flow pattern.
As the backend side can be wrote by many language, by various developers, so common pattern would make things more standard when we need some kind of migration, and even maintaining by new developer. If the project doesn't require ultra-secure authentication flow, the simplicity of first approach was enough.
From user convinient pespertive
Let's just imagine when changing an email address, what case the user likely want to change email address ? I was register my facebook account long ago using yahoo mail, that's no-longer active, and i need to switch to a gmail one. What's the point of sending the email back to the old one ? Cumbersome... and i can do nothing in this case except get some help from the staff.
I totally aggree with the second approach on security angle. But that's not suitable for most of the case, only implement if the project have some requirement. And even in that case, I suggest don't even do that too, build some thing like sub-admin account role and grant permission to someone have responsible. Like Google enterprise email organize some account called admin if anything wrong happen to user account. As long as it has this kind of security level requirement, it's not gonna serve massively user.
The intension of all the flow
The User got authorized first, right, that's mean we Identified what the user are, and what she capable to do. Imagine when we hide a hotel room then request to change to another due to some reason. What's the point of proving that's I booked my own room, since we all know that's the fact ? Kinda weird... right ?
To conclusion, I think we shouldn't mess with something that's become common pattern that widely acknowledged, except we have some special requirements and the project have something uniquely to satisfy, and we consider ourself, as developer that's reasonable.
The main problem with this approach is: what happens if the user no longer has access to their original email account? Perhaps it was a work/school/uni account that they no longer have, or perhaps they've just forgotten their password or otherwise lost access to it.
With your second approach, they are not going to be able to update to the new account, because they'll never receive the first confirmation link.
How about the following approach instead:
User requests an email change.
Require the user to re-authenticate with their current password (just like when they change their password).
Send a confirmation link to their new email.
Send a notification to their old email, with the details of the change, and instructions of what to do if they didn't initiate the change.
User clicks the link to update or contacts your support to say their account has been compromised.
This way you still provide them with an alert that someone is trying to change their email (and potentially a means to stop it), but a user who has lost access to their old account will still be able to update their email.
My Heroku account was flagged automatically and locked due to suspicious activity, which is good security. I raised a ticket with Heroku at the time to unlock the account, they required some information from me, including identity verification, which I provided. Since this they have not responded to my ticket and it appears a bot has automatically closed the issue, with no resolution.
Now it asks me to log a new ticket but I can't actually log in with my account to create a ticket. So I made a new account, logged a ticket with reference to the initial ticket and have had no response. About a week later, it appears my second account must be locked as I am unable to log in with this account. Probably valid since I had to create a temporary email account to sign up so I could raise a ticket.
The Heroku help docs are pretty useless. It's essentially an endless loop of Create Ticket > Help Center > Search > Read Article > Create Ticket...repeat. Even if I get to a sign in page I can't get by it anymore due to yet another account disabled.
That account is linked to my official email address and is why I'd like either the account unlocked or the email address released. It seems as though creating a new account isn't a viable solution either, given that I have tried and that account is now locked too.
I have tried the actions described at What should I do if I can't log into my Heroku account?
There doesn't appear to be any way of getting in touch with a human short of calling an office or a sales rep for enterprise which I feel is the wrong approach. Perhaps this is where my journey ends with Heroku although that seems unfair.
So instead of creating a spamming cycle of new accounts and tickets all referencing each other, how do I go about restoring access to my main account and initial ticket?
As the title says. This is the condition I have.
I wanted to make approval token before a user can do certain things. Here's my situation :
I have a web application made with Laravel 5.1
All user are already authenticated before they can use the web app
Before the user do any large transaction, the User needs approval from supervisor and in some case the director (software side). This is a preventive measure against fraud and employee stealing money.
Now I've been looking at a few solution but all that I've found are to further authenticate user when they login. I'm not sure I can modify it to do what I want.
Here are some of the solution I've been reading :
google 2fa
authy
This is the workflow I imagine to fulfill my need :
The user opens the web application and authenticate using their credential
The user navigate to a certain page and do a large transaction.
Before they press the "submit" button, the supervisor or the director must enter some kind of token (One Time Password perhaps) before the submit buttons activate.
On the server side, the application process all the inputs and authenticate the token (one time password), if the token (one time password) checks out, everything runs.
Can anyone gives me suggestion about the workflow? and Is there any solution to fulfill the needs?
I'm open to any suggestion.
Thank you very much.
*disclaimer : Sorry if the grammar is wrong or somethings are confusing, english is my 3rd language.
Customer want to restrict duplicate login for the App, once user login from another phone, the session of previous phone should be invalidated.
but I can't find the API for worklight to do this, besides using push, another suggestions? thank you very much.
Worklight indeed does not provide any API for this type of scenario.
Here is what I am thinking as an example of what can be done:
Device #1 is an Asus, device #2 is an LG
As the user log-ins, you will store the device information in the Worklight database (using WL.Client.setUserPref)
When the user will try to log-in again from another device, you could pull the existing pref (using WL.Client.getUserPref) and compare the device types
If they are not the same, logout current userId and re-login
(Consult the user documentation for additional API methods around userpref)
This could be a way to ensure the user is logged only from one device.
You could also use the userId associated with the deviceId and update upon every login if (currentDeviceId != latestDeviceId) logout(); and so on...
Here I have posted a implementation mechanism which strikes in my mind.
Its still a suggestion.
Whenever a user tries to login an entry can be made in backend[DB/Webserice] which tells about the user/device information.
If the user info is existing already then you can prompt a dialog box to the user The account has been logged in already, if you continue to login the previous session would be logged out trigger a push notification to the previously logged in user device, if user continues.
Now a notification will be reached to previously logged in device. Here you can implement the logic to execute the WL.Client.logout(realm, options).
It would be great if someone post answer better than what I did.
And also let me know if my suggestion was helpful or not.
I am facing difficulty in making my Ajax request secure.
The problem is Data tampering. I have read about this problem and it is suggested that never trust the information what ever is coming from client. It can be very well changed using fiddler or any such tool. We need to validate in server side as well. But my question is how to validate.
Let's see one example.
Suppose I have Employee information in database and I have exposed one method GetEmployeeDetailByEmployeeId. Before any employee make this request he will be authenticated with userId and password and authorized whether user of this type are allowed to make this request or not.
But if one employee gives employeeId of some other employee, he will actually gets the data which he is not supposed to see. To fix this issue we have two solution
1. We should check the request against the database, whether the information requested by the person is meant for him or he is the manager of that guy
2. We should somehow validate in app layer itself whether we should reject the call or not.
First approach is performance intensive where I have to make database request and finding the association of record, also it will add cost to development.
Pls suggest which way to go and do we have any better solution to solve this kind of problem.
Clearly you need to check it at your back-end side, otherwise your application is likely to exploit by a kid.
Update
you need to implement an authorisation mechanism in your back-end, then after you load the permissions at the beginning, you can add it to the user session, so you don't need to look-up the database each time, you just need to check the user permission against the task required permission.
More
To implement the authentication mechanism: Goal, user can see it's own profile but supervisor can see everyone within his department.
user A has the user_id already loaded at the session, let say user_id = 123
user A can only request his information so if (user_id == req_user_id) then show the information, otherwise show error.
user B has the permission value of 100, let's call him supervisor then. Now if (user_id == req_profile_id) is not true we will check the permission. Let say the task permission for this particular task is 10 so if (user_perm >= task_perm), go ahead and check the department, if both the requested user and current user are at the same department, then show the information, otherwise show an error.
this should works based on your information.