Customized login page



  • This happened about seven years ago. Some project manager had given me a "simple" task. I was to make it so that each user could have a customized login page, with different themes, elements and information for each one.

    "Great", I said, "but how do we know which user is using the login page? After all, the one prerequisite for them getting to that page is being, er, not authenticated."

    The PM scratched his head and walked away. A chain of emails between PHB's followed, with me being CC'ed on all of them. Someone then came up with the idea of leaving a cookie on the users' machines, telling us who had accessed the system last from any particular machine. We would fetch the customized login page for that user the next time someone tried to log in.

    One week later, the director calls me to his room. "WTF is this", he asked, "the login page is showing me information that I shouldn't have access to". That's because one of the features of these customized pages was showing the users any urgent messages they had, right from the login page*. And someone else had logged in from his machine.

    The cookie idea was then dropped right away, killing the customized login page feature, and a new chain of emails followed, this time involving the dev's. So yeah, you can't associate a login page with a particular machine, or a particular IP. I remember someone said, "how about associating it with the SO user, that could be done with ActiveX". Eventually someone even gave the idea of a pre-login. Which would mean, if implemented, a two-stage authentication process. Just so that you could use your own personal login, after being logged in.

    Fortunately the idea was put on hold until someone could come up with a workable idea. I think it must be on hold to this day.

    * Yes, I know what you're thinking, and I was opposed to that from the beginning, but then again I was just an intern.



  • How dare you replace management decision with reality!

    Just make it happen no matter how it impacts security, and don't get it wrong.. ever!

    No if only we could install lasers to burn out thier eyes when they get thier password wrong we could be set.

     



  •  Somewhere out there among the countless parallel universes there is a place where this plays out the way it should:

     

     "We need each user to have a customized login page, with different themes, elements and information."

    "That's a fucking retarded idea and you're fucking retarded for suggesting it. No."

    "Oh, ok."



  • There's nothing wrong with doing customized login pages. The most obvious solution to me is using subdomains, like clienta.company.com, clientb.company.com, etc. And in fact thousands of web services already do exactly that. So you agreeing with the idiotic cookie plan when there is an already-established much superior solution is WTF #1.

    The real WTF here is adding information that shouldn't be accessible until the user is logged in to the log in page. But you didn't emphasize that point, you put it in as a footnote. So. Weird.



  • Yes, customized login pages per company is easily doable with subdomains, not so easy to make customized pages per user, unless they each get a subdomain to themselves.

    What they really want, but don't know to ask for is a customized welcome page.  That is where user specific information should go.

    But then what do I know?

     


  • Discourse touched me in a no-no place

    @Renan said:

    I was to make it so that each user could have a customized login page, with different themes,
    So that's where the Yahoo "Sign in Seal" idea came from....



  • @KattMan said:

    No if only we could install lasers to burn out thier eyes when they get thier password wrong we could be set.
    If? Show some initiative and just do it!



  • Right, I'll get right on creating the laser emitting diode invented.  Can't be that hard since it is just changing light to laser and laser is just a form of light.

     



  • @KattMan said:

    Right, I'll get right on creating the laser emitting diode invented.  Can't be that hard since it is just changing light to laser and laser is just a form of light.

    You can get some blue laser diodes from a blueray player that can
    burn your eyes with the right power and collimation.  I believe this is
    where Wicked Lasers gets the diodes for their toys lasers, but I could
    be completely wrong.  They might get them from projectors.  This blue
    light is superior for burning your retinas out.  It won't just burn
    them.  It will photochecmically fuck them up.

    http://en.wikipedia.org/wiki/Blue-light_hazard#Blue-light_hazard

     

     



  • But can I make  killer Led monitor out of them?  i would think I need red blue and greens.



  • @pauly said:

    @KattMan said:

    Right, I'll get right on creating the laser emitting diode invented.  Can't be that hard since it is just changing light to laser and laser is just a form of light.

    You can get some blue laser diodes from a blueray player that can
    burn your eyes with the right power and collimation.  I believe this is
    where Wicked Lasers gets the diodes for their toys lasers, but I could
    be completely wrong.  They might get them from projectors.  This blue
    light is superior for burning your retinas out.  It won't just burn
    them.  It will photochecmically fuck them up.

    http://en.wikipedia.org/wiki/Blue-light_hazard#Blue-light_hazard

     

     

    Unneeded. The diodes from a cheap DVD burner will suffice since those are powerful enough to burn through cardboard.

    Laserplotter made from old DVD burners



  • @Rhywden said:

    Unneeded. The diodes from a cheap DVD burner will suffice since those are powerful enough to burn through cardboard.

    Laserplotter made from old DVD burners

     

    I approve of this so much.

     



  • @Renan said:

    Fortunately the idea was put on hold until someone could come up with a workable idea.
     

    The obvious solution is to have a standard pre-login page where the user enters their username and password.  This takes them to the customized login page where they enter their username and password again.

    I have not patented this idea so feel free to use it.



  • @KattMan said:

    Right, I'll get right on creating the laser emitting diode invented.  Can't be that hard since it is just changing light to laser and laser is just a form of light.

     

    Shouldn't be too hard. It's worth noting that superluminescent diodes (the really bright ones like a phone camera flash) are essentially laser diodes with one of the ends filed off (that's a hell of an oversimplification of the actual engineering, although the science isn't far off).



  • @RTapeLoadingError said:

    @Renan said:

    Fortunately the idea was put on hold until someone could come up with a workable idea.
     

    The obvious solution is to have a standard pre-login page where the user enters their username and password.  This takes them to the customized login page where they enter their username and password again.

    I have not patented this idea so feel free to use it.

    This approach is severely suboptimal because it is not idempotent. Instead here is what should be done:

    1. The user is sent to a pre-login page where he enters his username and password
    2. These credentials are securely transmitted via HTTPS to a pre-authentication server where the credentials are encrypted and stored in a database.
    3. The pre-authentication server hashes the username and passes it to a customization web service that returns a identifier for the specific branding associated with the username hash.
    4. The pre-authentication server calls the login form composition service and provides the branding identifier to build the dynamic content to be sent to the user (in the backend the composition service may contact a templating server but this is an implementation decision)
    5. The pre-authentication server injects in the dynamic content a unique session id associated with the encrypted credentials
    6. The users is redirected to a customized login page, where he enters his credentials again.
    7. The credentials are securely transmitted via HTTPS to an authentication server, who verifies the identity but also checks with the pre-authentication server that the session is valid and that the credentials are identical to the ones provided in pre-authentication.
    8. The authentication server sends the request to the workflow server, providing a pass/fail status as a parameter
    9. The user is redirected to the appropriate page in the workflow.

    This scenario is foolproof because if the user changes his password between the pre-authentication and the authentication the login will fail. The credentials must be identical.

    (Of course each server in this architecture is actually a geographically distributed cluster and/or a EC2 node.)



  • @Speakerphone Dude said:

    @RTapeLoadingError said:

    @Renan said:

    Fortunately the idea was put on hold until someone could come up with a workable idea.
     

    The obvious solution is to have a standard pre-login page where the user enters their username and password.  This takes them to the customized login page where they enter their username and password again.

    This approach is severely suboptimal because it is not idempotent. Instead here is what should be done:

    <Snipped other workable idea>

    This scenario is foolproof because if the user changes his password between the pre-authentication and the authentication the login will fail. The credentials must be identical.

     

    This has the (unintended?) benefit of stopping people logging in using someone else's personlised login page.

     



  • @blakeyrat said:

    There's nothing wrong with doing customized login pages. The most obvious solution to me is using subdomains, like clienta.company.com, clientb.company.com, etc. And in fact thousands of web services already do exactly that. So you agreeing with the idiotic cookie plan when there is an already-established much superior solution is WTF #1.

    The real WTF here is adding information that shouldn't be accessible until the user is logged in to the log in page. But you didn't emphasize that point, you put it in as a footnote. So. Weird.

    Pretty good troll, Blakey. 7/10.



  • The obvious solution is simply to use a querystring parameter and give the users profile-specific bookmarks to the log-in page if they want to use the customised one. Oh, and hide information needing authentication until after… authentication.



  • @blakeyrat said:

    There's nothing wrong with doing customized login pages. The most obvious solution to me is using subdomains, like clienta.company.com, clientb.company.com, etc. And in fact thousands of web services already do exactly that. So you agreeing with the idiotic cookie plan when there is an already-established much superior solution is WTF #1.

    That solution could do it. But I think I should have elaborated more on the context of the WTF.

    By company policy, everybody's usernames (including those of the customers) should follow the format company.<first name>.<middle initial>.<last name>. Also this particular system was already running on a subdomain. So a full personalized login page addres could go like http://www.mycompany.renan.c.sousa.system.initrode.com.pt/ . Ok, that would work, but would you really use that if you could just go straight to http://www.system.initrode.com.pt ?

    During my internship there me and my friends came to the conclusion that proposing a sensible solution to a WTF would only lead the PHB's into compensating for it with even more WTF's.



  • @Renan said:

    During my internship there me and my friends came to the conclusion that proposing a sensible solution to a WTF would only lead the PHB's into compensating for it with even more WTF's.

    Of course, clever interns trumps experienced managers. Typical.

    Until one has enough experience/skills/clout to get business people to explain their need instead of their own technical solution to their underlying need one will always feel that they are idiots. Actually when managers come up with a technical request it's usually because they feel that the technical people are idiots who don't understand the business and they try to bridge the gap between business and IT themselves (poorly, most of the time).

    In this context what was the goal of having those custom login pages? Was there a higher purpose that could have been served by a more sensible technical solution? If the technical people had been explained what is the business driver (what and why) they could have done a better job. They deserve half the blame for not asking.



  • @Renan said:

    By company policy, everybody's usernames (including those of the customers) should follow the format company.<first name>.<middle initial>.<last name>. Also this particular system was already running on a subdomain. So a full personalized login page addres could go like http://www.mycompany.renan.c.sousa.system.initrode.com.pt/ . Ok, that would work, but would you really use that if you could just go straight to http://www.system.initrode.com.pt ?

    Obviously if you need custom login pages per-user my idea won't work. I had no idea that was what we were talking about here, this is the first it's been mentioned.

    99.9999999999999999999999999.9999999% of the time when people say "custom login page" what they mean is, "ok so our client is Foo, how do we put a Foo logo and color scheme on their login page while Bar retains their own logo and color scheme?"



  • @toth said:

    Pretty good troll, Blakey. 7/10.

    That wasn't a troll, that was a legitimate solution to the original post's problem. (Although now that the problem has been clarified, it's obviously not a very good solution. But, surprisingly, I don't fucking read minds.)



  • @blakeyrat said:

    Obviously if you need custom login pages per-user my idea won't work. I had no idea that was what we were talking about here, this is the first it's been mentioned.

    @blakeyrat said:
    But, surprisingly, I don't fucking read minds.

    @Renan, in the OP said:

    I was to make it so that each user could have a customized login page

    TEE HEE



  • @Speakerphone Dude said:

    @Renan said:

    During my internship there me and my friends came to the conclusion that proposing a sensible solution to a WTF would only lead the PHB's into compensating for it with even more WTF's.

    In this context what was the goal of having those custom login pages? Was there a higher purpose that could have been served by a more sensible technical solution?

    One customer came up with the idea during a meeting, and someone from Marketing said "hey, that would be a neat feature, we're going to do just that". And He said that to the customer, who then made a point of having it delivered. From there to requirements it was just a step.



  • @Renan said:

    One customer came up with the idea during a meeting, and someone from Marketing said "hey, that would be a neat feature, we're going to do just that". And He said that to the customer, who then made a point of having it delivered. From there to requirements it was just a step.
     

    There's the source of the WTF:

    1. agreeing to requirements without any analysis of feasibility, time or effort
    2. committing the organisation to that delivery
    3. poor stakeholder analysis for that meeting
    ... and IT gets it in the neck when miracles aren't forthcoming...


  • @Cassidy said:

    @Renan said:

    One customer came up with the idea during a meeting, and someone from Marketing said "hey, that would be a neat feature, we're going to do just that". And He said that to the customer, who then made a point of having it delivered. From there to requirements it was just a step.
     

    There's the source of the WTF:

    1. agreeing to requirements without any analysis of feasibility, time or effort
    2. committing the organisation to that delivery
    3. poor stakeholder analysis for that meeting
    ... and IT gets it in the neck when miracles aren't forthcoming...

    IT is not Agile enough! Let's send a manager to a 2-week Scrum Training session in Honolulu.


Log in to reply