private Tender URLs show SSO-ignorant login form, even with SSO
I've been wondering why a bunch of our customers - who are mostly developers and relatively clued - keep ending up with 2 different accounts on Tender, and repeatably have a problem figuring out how to sign in. I think I figured it out. We use Tender's SSO and have it link back to our login URL. If an unauthenticated user hits our Tender site and clicks Login, they'll be redirected to our login URL and all will be well.
However, if they click a link to a private ticket (like from an email), they're presented with a login page that has a Tender login form and no warning that the login form is not related to their existing SSO Tender account. When they try to login with their service creds, it inexplicably fails.
Unless I'm missing something about the way this was intended to work, this is really nonintuitive. It means that clicking Login on Tender's login page has inexplicably different behavior from submitting the login form - one redirects, one uses Tender auth.
I think it's why a double-digit percent of our users have unintentionally created 2 Tender accounts: one linked from SSO and then one directly on Tender under a different email address ("WTF, I already have an account but can't use it!!").
I think the most obvious fix would be to make login pages for SSO-enabled Tenders show a fairly loud message instead of a login form. "Have an account on Service Name? Login here>>
Don't have an account? Login here>>"
The first "Login here" would redirect them to the service login URL, passing the private ticket URL so we redirect them back. The second "Login here" would display the existing Tender login form (because even with that message, if the login form is still shown by default, people will use it and ignore the message).
Let me know if I'm just missing something obvious. Hope this helps.
Discussions are closed to public comments.
If you need help with Tender please
start a new discussion.
Keyboard shortcuts
Generic
| ? | Show this help |
|---|---|
| ESC | Blurs the current field |
Comment Form
| r | Focus the comment reply box |
|---|---|
| ^ + ↩ | Submit the comment |
You can use Command ⌘ instead of Control ^ on Mac
Support Staff 1 Posted by Courtenay on 08 May, 2010 05:53 PM
Ah! This does help, thank you. We'll dig into this a bit further and make
sure that it actually uses the login url, and that the url has the return
param to the page they're requesting.
2 Posted by Troy on 08 May, 2010 06:01 PM
Thanks Courtenay. Tender's login failure page does say "This site supports
cross-site logins. Please login to your Service Name account and you'll be
automatically logged into Tender Support" with the right login URL, but I
think it's too little too late - people see a login form and jump. If that
message was shown on the login page, bigger, in lieu of the form, I think it
would be golden.
Troy
Support Staff 3 Posted by Courtenay on 08 May, 2010 06:11 PM
Definitely. Thanks for the detailed report.
4 Posted by Troy on 16 May, 2010 03:17 PM
Thanks! As a v0.1 that would be a huge improvement and seems easy, I'd love if you can put the same "This site uses SSO, if you have a ServiceName account, click here to login" sentence on the login page that's shown to anon users when they hit a private discussion URL, and on the Create Your Profile page.
Those 2 quick changes would probably eliminate 50%+ of the confusion.
Thanks,
Troy
5 Posted by Elias Torres on 18 Jun, 2010 03:27 PM
This comment was split into a new private discussion: private Tender URLs show SSO-ignorant login form, even with SSO
I'm having a lot of problems with users trying to authenticate at your login. I'd love if it we had SSO enabled, that we don't display a login form and simply redirect to our Tender login URL.
Maybe as a custom setting. ;-)
6 Posted by Troy on 26 Jul, 2010 03:36 PM
Hey guys, if my seemingly-easy workaround above isn't going to happen anytime soon, can you let me know so I look for a new support service? It's been 2 months for literally a 1-line addition to the private ticket login page text (adding "Have a account? Click here" to the existing "Log in to a valid user profile")
It's ridiculous to show users a login box with no mention of SSO, and I'm frustrated that nothing has been done. It reflects very poorly on us. Our users create a second account needlessly, and then still can't see the ticket they created when they were logged in via SSO. I'm done explaining to our users why they were shown a login/password form without any mention of how to login to their real account.
7 Posted by Elias Torres on 26 Jul, 2010 03:54 PM
Troy,
I'm with you. We need a solution to this ASAP. It's really annoying. I've begun trying Assistly.
8 Posted by brian on 26 Jul, 2010 04:57 PM
Ditto on this - we tried hiding the form fields using custom CSS. That works great, but then we can't log in directly ourselves. :)
9 Posted by Will on 26 Jul, 2010 07:42 PM
Hey guys. Just a quick update on this. We are working on it. SSO workflow is our #1 focus on the development side right now. I just spoke to Zack and he said we should be in QA early this week to check things over.
We'll keep you updated as we go.
10 Posted by Will on 27 Jul, 2010 08:26 PM
We've got the SSO update in QA now. fingers crossed
11 Posted by Elias Torres on 05 Aug, 2010 02:20 AM
Hi Will,
Any updates on this? I was wondering if we could at least take a peek of what's coming? I know it happens at my company that I code something like a madman to end up being the wrong thing altogether.
Thanks and keeping my fingers crossed!
12 Posted by Will on 05 Aug, 2010 02:28 AM
We deployed an update to SSO on Friday, and had to scale back a few areas of it as it was a little overzealous of a push with our Server move Thursday night.
Right now, there is no more create profile option if SSO is enabled. I noticed that logins off email URLs are not redirecting to SSO logins, so that's a little tricky where we want to force behavior or not.
13 Posted by Elias Torres on 05 Aug, 2010 02:39 AM
Something like this?
If we enable SSO shouldn't ALL unauthorized requests be sent to OUR login form with the appropriate redirect URLs parameters? Regardless of source such as email or browser link.
Of course I don't know all of your use cases or details, but passing along some feedback of how I would expect our integration to work.
Thanks for the update!!! I'm psyched since we really need this...
14 Posted by Troy on 11 Aug, 2010 07:09 PM
I'd even be satisfied with starting the text that you pasted - regardless of whether the form is still shown. If the form/local auth does get removed, it should be a separate option from enabling SSO, since the form has been shown regardless for 2 years.
My bug report here is simple, so simple that it seems to have been lumped into other unrelated changes yet not actually implemented. The bug report is that when visiting a private Tender URL (like from an email), the landing page says absolutely nothing about SSO. All I want is the "please login to your account" added (as is on the main login page).
In the past week or two, it got changed to say "If you are "", enter your email address to receive the special URL to this discussion." next to a sidebar prompting people to sign up for an account (somewhere). I'm bowing out of the discussion now, as I've added all that I possibly can.
15 Posted by gary on 25 Aug, 2010 10:49 AM
Why oh why can you not solve this?
It is absolutely critical, our customers have multiple accounts with multiple loging because of this.
Whilst this problem exists SSO is completely redundant isn't it?
Please fix this asap. It is much more important than reports.
Thanks
Gary
Support Staff 16 Posted by Courtenay on 25 Aug, 2010 08:07 PM
Hey everyone,
We're working on this. There are a few use cases, and we're trying to keep it simple and functional for everyone. Thanks for your patience.
Support Staff 17 Posted by Courtenay on 26 Aug, 2010 01:41 AM
Hey all, what do you think about this?
Note this is for private sites only (e.g. those in beta)
18 Posted by Elias Torres on 26 Aug, 2010 02:38 AM
That's looking like it will do it!
Regards,
Elias Torres
CTO
www.performable.com
+1-781-285-8678
Follow me on Twitter: http://twitter.com/eliast
19 Posted by Troy on 26 Aug, 2010 02:58 PM
Courtnay, thanks for the concept screen. I think there's a couple requests/use cases that have been jumbled into this single ticket, and thus into the screen you posted. Can you clarify which you are trying to or want to solve? The ones I've seen:
Make it clearer that people with core service logins should login through the service, not Tender. This was my original ticket, and was to add 1 line on 1 page.
Disable Tender logins for SSO Tenders. I don't and didn't need this, and I think that if it's enabled, it should be (or have been) a separate option than whether to use SSO at all. Even if this should have been the default for SSO from day 1, lots of us have folks who did create Tender accounts.
Some form of either invitations or email domain-based access, which I didn't see in the history but seems to have come up in the concept.
Can you clarify which of these you're trying to solve?
My take on the signup screen you posted is that it's too complex for someone who knows nothing about Tender and is looking for support for My Crazy App. When it takes 5 paragraphs to tell someone how to decide how they should go about getting an account, something might be wrong. I think if you want to support all these knobs, the login-or-create landing page needs to be simpler, and the rest of the choices only shown after they pick a very simple first choice.
That very simple first choice might be "I have an account on My Crazy App" (takes them to service login page) or "I don't have an account" (shows big "Apply For Access" button and a tiny link for "I've used Tender before"). Basically, instead of using text that people won't read (and as written, won't understand), make it a couple choices. Or remove the non-core stuff (invites?) from the first change; I think trying to tackle too much in a single change is why this thread is so long.
Thanks and good luck,
Troy
20 Posted by gary on 03 Sep, 2010 08:55 AM
Please don't implement that screen above, it's complicated to say the least...
We have a workaround for the sign-in problems that is working well will the current system so if you do implement changes please make them optional not forced.
One feature that would finally sort everything out would be to only allow logged in users access to the private button when starting a discussion.
Logged in users = private/public
Non-logged in users = public
This would sort out 99% of the problems we are seeing.
Many thanks
Gary
21 Posted by cstoe on 27 Oct, 2010 03:16 PM
you can also hide the sign in form of the sign on page with CSS.
Still trying out how to format a custom message on that page with CSS. cant allow /'s so not sure....but at least have the sign in form hidden...
div.form {
display: none;
}
Support Staff 22 Posted by Courtenay on 13 Nov, 2010 01:59 AM
Hey all,
This is our top priority after the big launch on Monday of our new admin site. We'll likely have a few solutions to solve the various issues you've all come up with. Thanks for sticking by.
23 Posted by cstoe on 19 Nov, 2010 01:38 AM
ok - i have hid the login form using my above code, but when i try to hide the default message, "the site supports cross-logins........" by display: none on the class "columns", it hides many other features within tender, because columns is a shared class across many functionalities.
this still could be ok, if a div was assigned to the
within columns on this page that contain these default messages.
or re-name columns to something else on this page.
thanks!
Support Staff 24 Posted by Courtenay on 19 Nov, 2010 01:42 AM
The body has an ID you can use to scope your CSS. Does that help?
25 Posted by cstoe on 19 Nov, 2010 02:16 AM
Aha! yes...worked like a charm! now our SSO is working perfectly...and users do not see options to create/login to new account!
thanks for the tip....here is the code:
body.page-sessions_new.section-sessions.logged-out.private-notification div#content div.columns {
display: none;
}
Support Staff 26 Posted by Courtenay on 19 Nov, 2010 02:28 AM
Great. We're still going to work on the flow of SSO and login so you
all don't have to hack it. Stay tuned ;)
27 Posted by Mitch on 06 Dec, 2010 10:39 PM
Hi team
Just wondered if there way any update on this? At the moment we've hacked the SSO WordPress plugin so we can make links like this, but it's not ideal:
'<a href="http://domain.com/faqs/getting-started/article?sso=' . unique_sso('http://test.tenderapp.com', 'abcd1234uniquekey', 'client-name') . '" title="Click here">Click here</a>.Loving Tender 2.0 by the way!
28 Posted by Mitch on 14 Dec, 2010 04:16 AM
Hi there
Just wanted to follow up on this as we've tried to hack our way into a better situation this week and realised we were up against a brick-wall.
The code above does work well as a stop gap for any fixed links we put up on our intranet, but we're stymied by the fact we can't easily email out links to knowledge base pages: when we do, users hit the default Tender sign-on page, follow a link back to our intranet and then, hopefully, click on the "Support" SSO link then find the knowledge base article by browsing or search.
Ideally, as mentioned above, we'd love it if we could send a deep link to the appropriate knowledge base article. Then—if the user isn't logged in—there's a clear path to pass the correct URL parameters to our authentication system (WordPress) so they can login, pick-up the Tender SSO cookie, then be redirected to the knowledge base article they were looking for. That would be golden.
Thanks again!
29 Posted by caleb cohoon on 14 Dec, 2010 10:49 PM
Great discussion. Looking forward to seeing a solution. :)
30 Posted by Chris Marisic on 11 Jan, 2011 02:55 PM
What is the status of this? I have an organization of approximately 30 users that I am weighing whether or not we adopt Tender and this is an absolute deal breaker.
There is absolutely no way I want to present an experience to our users that causes confusion about creating multiple accounts. We have enough issues with that where users of our site create duplicate accounts instead of recovering their existing accounts to start with. I don't want this spill out into an even larger problem.