6 ms·

Is it satire because many of the buttons and links don't work so you can't actually finish anything? If it’s serious, I doubt it provides much real value. Deve

by molf 2y ago

Is it satire because many of the buttons and links don't work so you can't actually finish anything? If it’s serious, I doubt it provides much real value. Developer experience is built on accomplishing actual tasks, not the surrounding administration and ceremony. Aspiring devs should probably work on personal/toy projects or open source. That said, it looks great—well done!

pinoy420 2y ago
Great feedback. Others can learn from you
eterm 2y ago
The outstanding task of "Implement OAuth" being overdue nearly a year hits too close to home.
- zwnow 2y ago
  Whats good about OAuth if you dont require Authorization though? Most apps I know of mostly only need Authentication. Never implemented it myself so I really want to know
  - kvdveer 2y ago
    Maybe I'm zooming in too much on semantics here, but I have a hard time imagining an application that needs authn, but not authz. Even editing your own preferences requires authz, as other people shouldn't be able to do that.
  - deleted 2y ago
    [deleted]
  - eterm 2y ago
    Often when people ask for Oauth they really mean OAuth2/OIDC, and what they really want is managed authentication, with further authorisation being managed at the application level rather than through oauth. The advantages are there: 1. Reducing sign-up friction. Despite how much this crowd dislike such things, it's much easier for most people to hit "Use google login" or "use facebook login" than create a new account. One less password to remember ( or one less place to store the same password you use everywhere ) for people without password managers. 2. People trust "Google" or "Facebook" more than they trust random service they're just checking out. Having that "sign in with google" extends that trust to your service. 3. If you ever do need Authorization, it's much easier retro-fitting that if you already have OAUTH than trying to retro-actively fit it all to get that authorization. 4. Letting someone else take care of user account cancellation. Businesses hate it when there's no OAUTH, because they don't want to have to track down and change / cancel accounts when someone leaves their organization. They want to suspend/remove them from their Azure AD / Octa / etc and that user instantly becomes persona-non-grata across all services. They might also want to have different groups at their end, so they're still the same identity, but lost authorisation to log into <Service> now they moved from an ops role into development, for instance. They're still the same identity and same authenication in this case, but should no longer be authorised for your service.
    - PedroBatista 2y ago
      This. At any big company, if you’re doing software you’ll be doing OAuth/OIDC like it or not.
    - zwnow 2y ago
      So for the sake of simplicity devs offload authentication to some 3rd party provider? Oauth/2 is for authorization though, i dont get where the authentication part comes from. They even write it is an authorization protocol.
      - eterm 2y ago
        OIDC describes itself as: "OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 framework". So Oauth2/OIDC is what you typically want? I don't really understand the details well. I understand what vendors and customers are after. I wouldn't ever try to write any clients/servers myself for this stuff.
        zwnow 2y ago
        Why though? Why are devs so afraid of auth?
        eterm 2y ago
        I'm not afraid, I just don't understand the nuances well enough. But it's also easy to understand what there is to be scared about: 1. Security critical. 2. Single source of failure. ( If your auth fails, it doesn't just break one feature or aspect, it takes everything and everyone down with it. ) 3. Performance critical. It's a bottleneck in most applications, it's very rare and even more difficult to get distributed auth working, if you factor in repudiation / token cancellation. It's not an area you can "fake it 'til you make it" or "move fast and break things" with. Even just "buying" the solution isn't easy. Actually implementing your own OIDC client/server solution is a large project that only makes sense to dedicate a team to in the largest of organisations.
  - antonvs 2y ago
    In any company of any non-trivial size, and even many smaller ones, authorization is a big deal that tends to permeate all the systems. For example you don’t want most staff to be able to log into the payroll system and change salaries. But they can log in and look at their own records. That behavior requires authorization either way. If you then add outside people or companies to that, it becomes even more complex. Most companies aren’t in the business of implementing their own distributed auth system, and wouldn’t be able to do a good job if they tried. So they buy an implementation of a standard system like Oauth.
  - Scarblac 2y ago
    It's the other way around, if you don't need authorisation, why would you need authentication?
    - zwnow 2y ago
      To identify a user and grant them access to their own data
      - eterm 2y ago
        The "their own" part of your statement is what some (many?) consider to be in the authorization domain. Discussions around Auth are typically confusing. This is not helped by authentication and authorisation sounding similar, but also because it is difficult to keep track of whether what is being discussed is first party or third party. Most apps don't need third part authorization, although some do. For example if I were to use Cisco Meraki Oauth, then the third party authorization of which parts of the network were visible to me as a service is critical. On the other hand, if I'm just using them as an easy way to provide authentication for a service which I only want to target to Meraki customers, then I don't care about the third party authorisation, and just need the authentication part. I still need first party authorization on my own system to keep different users' preferences separated. Another source of confusion also mixing discussions of intra system authentication + authorization with external authentication + authorization. I've seen lots of discussions of JWTs for example which quickly start talking about local services, whcih might be better handled by not having the user involved at all, and just having a secured pipeline between services. You often don't need to have passthrough authentication/authorization, although again there are advantages and disadvantages to organizing services in this manner.
      - Scarblac 2y ago
        "Granting access to data" is what authorisation is.
KomoD 2y ago
> That said, it looks great—well done! All they did was generate it with https://lovable.dev https://lovable.dev That's why basically nothing works.
- notpushkin 2y ago
  Oh wow. So you can put in a prompt, get a mockup of an app and get to the front page of HN with that now?
  - edgineer 2y ago
    The idea-execution value gap is shrinking.
mycall 2y ago
I didn't see 100 emails or supervisor interruptions buttons.
- ZaoLahma 2y ago
  Love it. Also needs to simulate getting responsibility without authority, with weekly meetings to follow up on your progress.

by molf 2y ago

pinoy420 2y ago

Great feedback. Others can learn from you

eterm 2y ago

The outstanding task of "Implement OAuth" being overdue nearly a year hits too close to home.

zwnow 2y ago
Whats good about OAuth if you dont require Authorization though? Most apps I know of mostly only need Authentication. Never implemented it myself so I really want to know
- kvdveer 2y ago
  Maybe I'm zooming in too much on semantics here, but I have a hard time imagining an application that needs authn, but not authz. Even editing your own preferences requires authz, as other people shouldn't be able to do that.
- deleted 2y ago
  [deleted]
- eterm 2y ago
  Often when people ask for Oauth they really mean OAuth2/OIDC, and what they really want is managed authentication, with further authorisation being managed at the application level rather than through oauth. The advantages are there: 1. Reducing sign-up friction. Despite how much this crowd dislike such things, it's much easier for most people to hit "Use google login" or "use facebook login" than create a new account. One less password to remember ( or one less place to store the same password you use everywhere ) for people without password managers. 2. People trust "Google" or "Facebook" more than they trust random service they're just checking out. Having that "sign in with google" extends that trust to your service. 3. If you ever do need Authorization, it's much easier retro-fitting that if you already have OAUTH than trying to retro-actively fit it all to get that authorization. 4. Letting someone else take care of user account cancellation. Businesses hate it when there's no OAUTH, because they don't want to have to track down and change / cancel accounts when someone leaves their organization. They want to suspend/remove them from their Azure AD / Octa / etc and that user instantly becomes persona-non-grata across all services. They might also want to have different groups at their end, so they're still the same identity, but lost authorisation to log into <Service> now they moved from an ops role into development, for instance. They're still the same identity and same authenication in this case, but should no longer be authorised for your service.
  - PedroBatista 2y ago
    This. At any big company, if you’re doing software you’ll be doing OAuth/OIDC like it or not.
  - zwnow 2y ago
    So for the sake of simplicity devs offload authentication to some 3rd party provider? Oauth/2 is for authorization though, i dont get where the authentication part comes from. They even write it is an authorization protocol.
    - eterm 2y ago
      OIDC describes itself as: "OpenID Connect is an interoperable authentication protocol based on the OAuth 2.0 framework". So Oauth2/OIDC is what you typically want? I don't really understand the details well. I understand what vendors and customers are after. I wouldn't ever try to write any clients/servers myself for this stuff.
      - zwnow 2y ago
        Why though? Why are devs so afraid of auth?
        eterm 2y ago
        I'm not afraid, I just don't understand the nuances well enough. But it's also easy to understand what there is to be scared about: 1. Security critical. 2. Single source of failure. ( If your auth fails, it doesn't just break one feature or aspect, it takes everything and everyone down with it. ) 3. Performance critical. It's a bottleneck in most applications, it's very rare and even more difficult to get distributed auth working, if you factor in repudiation / token cancellation. It's not an area you can "fake it 'til you make it" or "move fast and break things" with. Even just "buying" the solution isn't easy. Actually implementing your own OIDC client/server solution is a large project that only makes sense to dedicate a team to in the largest of organisations.
- antonvs 2y ago
  In any company of any non-trivial size, and even many smaller ones, authorization is a big deal that tends to permeate all the systems. For example you don’t want most staff to be able to log into the payroll system and change salaries. But they can log in and look at their own records. That behavior requires authorization either way. If you then add outside people or companies to that, it becomes even more complex. Most companies aren’t in the business of implementing their own distributed auth system, and wouldn’t be able to do a good job if they tried. So they buy an implementation of a standard system like Oauth.
- Scarblac 2y ago
  It's the other way around, if you don't need authorisation, why would you need authentication?
  - zwnow 2y ago
    To identify a user and grant them access to their own data
    - eterm 2y ago
      The "their own" part of your statement is what some (many?) consider to be in the authorization domain. Discussions around Auth are typically confusing. This is not helped by authentication and authorisation sounding similar, but also because it is difficult to keep track of whether what is being discussed is first party or third party. Most apps don't need third part authorization, although some do. For example if I were to use Cisco Meraki Oauth, then the third party authorization of which parts of the network were visible to me as a service is critical. On the other hand, if I'm just using them as an easy way to provide authentication for a service which I only want to target to Meraki customers, then I don't care about the third party authorisation, and just need the authentication part. I still need first party authorization on my own system to keep different users' preferences separated. Another source of confusion also mixing discussions of intra system authentication + authorization with external authentication + authorization. I've seen lots of discussions of JWTs for example which quickly start talking about local services, whcih might be better handled by not having the user involved at all, and just having a secured pipeline between services. You often don't need to have passthrough authentication/authorization, although again there are advantages and disadvantages to organizing services in this manner.
    - Scarblac 2y ago
      "Granting access to data" is what authorisation is.

KomoD 2y ago

> That said, it looks great—well done! All they did was generate it with https://lovable.dev https://lovable.dev That's why basically nothing works.

notpushkin 2y ago
Oh wow. So you can put in a prompt, get a mockup of an app and get to the front page of HN with that now?
- edgineer 2y ago
  The idea-execution value gap is shrinking.

mycall 2y ago

I didn't see 100 emails or supervisor interruptions buttons.

ZaoLahma 2y ago
Love it. Also needs to simulate getting responsibility without authority, with weekly meetings to follow up on your progress.