The fact that there are so many reasons for the failure itself tell why the failures are so frequent. I strongly believe that it should be more than just the development teams which should be attributed for failures. Projects rarely get delayed or fail cause of developers only, the more responsible parties are management and the company culture. Even the strongest of the developers would learn over period of time that sticking to a more realistic schedule would not earn them praises. Unfortunately the path to promotion is to keep the bosses happy in most places. Most people do not have motivation about the end results, its more about looking good on day to day basis.
Keeping the failures aside what has worked for me in the past is to add little padding (10%-20%) to all the tasks which no one would question and then we have enough padding to cover for any task in which the team really spent around 1000% percent more time than estimated. Again it really depends on how much the product people understand the efforts involved in development. Its hard to make some one believe that one line change took 3-4 days and another 1000 lines were added in half a day if they have not been there themselves.
Assuming that you are referring to browsers as client here. One simple reason is that the client side data can always be manipulated so it does not really makes any difference. It might just give a false sense of safety but does not changes much.
In case we are talking about multi-tier applications where probably LDAP or AD is used to store the credentials then the back end is the one responsible for doing the hashing.
This is indeed an important discussion. I was looking for some similar experience in the top few comments but couldn't find it, so I thought about writing my own. From my experience its about the person in the role, not the role itself. Two of the best managers I had were non-technical but they could read people. They kept their distance from the technical work but would step in when required to control. Ofcourse this also means that they hired good engineers to begin with. A good engineering team can run by itself when it comes to technical work.
This is a pretty common trend in lots of places. These kind of decisions are driven for things other than computing needs. Maybe to look cool/cloudy/nextgen ...
Tangential answer: It would vary based on sensitivity of your application. JWT is not a bad option if we do not have a requirement of absolute session termination and if implementation does not have any vulnerability. People also use cookie shared on the root domain(backend and front end can be served by different sub domain. Also you can use custom headers since cookie is just another type of header managed by browser itself. The additional work would be around managing the additional header on back end.
People generally open doors for CSRF attack by separating front end and backend like this. Good thing is that there are simple solutions to mitigate that risk too.
There is no single good answer to this question without taking into account the security consideration of the API in question and the consumers. On a high level all solutions work just fine as long as we understand the tradeoff's involved (cpu, IO, revocation, complexity,..).
The different solutions that could be tried with ease are:
1. Network filtering - If the API consumers can be limited by identifying their IP addresses
2. Bearer tokens - Simple random string that can be passed in the header (depending on number of consumers, ability to revoke/change tokens it can become little complex)
3. JWT's - Similar to bearer tokens without the ability of revocation and extra cost of key management and CPU (the signature verifications are quite costly).
4. OAuth - Better call it 2-legged OAuth since its between servers only. Its the ideal one with both revocation possibility and signature verification.
The first three could be implemented easily inhouse and are suited when number of consumers are small. Its better to use some third party SAAS service or OAuth server for the fourth one. I work professionally on these things and these implementations can be time consuming. More than often people dont take into account their requirements when choosing a solution.
This is a common problem with more and more companies relying on SAML federation. A part of this problem is solved by using SCIM provided your IDP and service supports it.
Ironically even though SCIM is a protocol, the implementations vary across different IDP,s.
A second common issue is ability of changing the email addresses in AD, this breaks the mapping cause most of the times email is primary identifier.
1. As an engineer I would definitely not work with a team that comes up with the first reason for rejection (Provided that I have not mentioned that stack on my resume to begin with).
2. The second reason is more of a choice of the given company. There are companies on the other hand which give out an offer all based on cultural fit. More than often good interviewers never make a decision on the result of the puzzles but on how the candidate approaches it. Downside is that not all people are up for it in the interview hour even if they are really smart otherwise.
3. Third is bad luck (cause of disorganized recruiting). The delay in response has something to do with the candidate too, how much vulnerable they are for the job. Personally I discuss the expectations for the interview process beforehand which is super helpful since I almost always get the feedback the next day irrespective of whether its an offer or rejection.
On the flip side there should be another discussion on how engineers get the jobs. I am sure those stories would be interesting too. It is not about the technical competency for majority of the times. Interviewing is an art and the candidates who are able to make the interviewers feel good about themselves have much more chances of offers.
Hi HN, We are providing a simple to use service to validate the user email addresses at the web doorway for the businesses. We validate the email addresses for more than just the syntax. The goals are three folds, First, give another chance to the real users if they made a typo mistake with their email. Second, Filters the people from entering spam emails with correct syntax. Last, as business/website owner you will have less fake users to chase and waste the monetary and time resources
The service is free to use for the trial period. Thought has been put into making it simple enough to integrate. Integration does not requires any programming skills. We would really appreciate the feedback from the HN community on how we can improve this and make it more usable.