Invoice link that can be set to expire

As stated in the linked feature request, I think this should be considered a bug and a security hole.

From a test I just did with a fake customer, you can get into the customer's portal and change the password using an old magic link. This looks like a bug more than a feature to me. Also kind of a big security threat.

Note that although the user asked for this feature under V4, I tested on my instance running V5.


If you feel the links aren’t secure enough for your needs you can enable a password on Settings > Client Portal.

Do you mean this option?

Not sure what it does as even if it’s set to off, the user can still set a password with the magic link by going to his account and set a password. I’m guessing this asks him to set a password directly rather than it being an option, but does it changes the fact that you can connect using an old magic link?

On my end, turning it on or off doesn’t change anything if I use a previously generated link and I don’t see a way to disable a previously generated link.

I guess the question really is: is there any way to disable a previously generated link?

My suggestion would be to have some sort of interface showing generated links.

I’m guessing something like throwing the content of a
select * from whatevertablestoreslinks where customer = x
in a table with a basket allowing deletion of said link would be enough to silence those pesky users without too much trouble.

Then other features like expiration and whatnot could be added if you ever so choose but at least there would be an option straight in the interface allowing for links “control”, other than asking the end user to fiddle in the database.

If you delete the invoice or remove the contact from the invoice it will deactivate the link.

I would advise against that as this is flirting in illegal territory unless of course you’re using invoice ninja as a simulation game.

Tempering with legal documents (invoices and reports) to work around an oversight in a software seems dodgy to me. The software is great in many ways so you’ve done fantastic work all around. This genuily seems like an oversight imo.

I’d add that I don’t want to hurt anyone’s feelings or make this harder than it has to be.

To be absolutely clear I’m not saying “You have to do this!”; nobody can tell you what you have to do with the software you make. What I’ll say is I’d rather be told some cold truth like: “We won’t do it because we don’t want to. End of discussion.” than waste time arguing about something obvious. Agreed?

@david any thoughts?

magic links should expire after 5 minutes.

@kbftech are you seeing magic links persisting longer than this?

@david that’s odd, in my test they seem to last “forever”. There must be something wrong on my end if the links are supposed to expire after 5 minutes.

If i’m getting your comment right, the expected behavior is for the links to expire 5 minutes after having been clicked for the first time. That seems perfectly appropriate behavior and I’m guessing something odd is going on with my tests.

Here is what I did:

  • Created an invoice for a new customer (no profile/password, never went on his portal at this point)
  • Clicked on the link through email
  • Set a password
  • Clicked on the link again (days after)
  • Still got in (without entering a password)

I’m going to try again with a different new customer and see if I can do it again from scratch.

Thanks for getting back and if you have any input, let me know.

If password protection is ON, then the user would need to enter the password. If they can go straight through then that is not the expected functionality.

If the session is persisting, the cookie may still be alive which would auto-authenticate the user as the session is still persisting.

I think I found the “issue”. Let me know if I got this right:

  1. The magic link is never deleted.
  2. It is rather checked if valid upon http request (when a user clicks it), against specific conditions (such as time).
    The conditions can be bypassed if you are indeed logged-in, even as a different user.
    The UI will show the customer’s portal, but you’ve got in through a different user authentication (admin for instance).

I’m guessing the intended purpose is for the user to access his own portal through an old e-mail link, maybe? My understanding is that the magic link is never deleted from the database and checks are bypassed when using a different user. Now I’ll have to create another customer and see if I can reach a different customer’s portal by being logged in as a customer, which I would expect to fail obviously.

Then I would test with a different admin, which isn’t supposed to have access to that specific customer (either by not being a customer of his, or by not being admin for that specific company.

If all thoses fails, I guess there is no issue as a legit admin, and a legit customer having access to portals isn’t that big of a deal.

NOTE: Just saw your reply and I think you’ve got something regarding session/cookies. I tried with with a private browser window and sure enough, if I’m not logged in at all, the magic link just gets me to the login window.

NOTE2: All of this is done with Password protection set to “ON”.