Magic links landing page

[talder]

Hi,

I was wondering if there could not be an option made to show the magic links. If you forget them, then you have to generate new ones and redistribute them to some users. (I know that's the point for it, but any user with this links can just run your jobs)
Maybe secure them with a passphrase or something that the user must specify when landing on the page? Any other ideas to make this possible? I really like this feature, but it is a bit restrictive that you cannot reveal the link afterwards.

Kind regards,

Tim

[jhuckaby]

Unfortunately for security reasons the magic links aren't even stored in the database. All I store is a salted SHA-256 (one-way hash). So there's no way to reverse it and retrieve the original links. That's why they are only offered to you once -- they only can ever be offered once. API keys are handled in the same way. This level of security is a hard requirement for many companies.

What I CAN offer you, however, is perhaps an easier way to "regenerate" the magic link, which would REPLACE the old one (invalidating it) with a newly generated one. Would that suffice?

[jhuckaby]

Okay, xyOps v1.0.1 was just released, which bumps the web server (pixl-server-web) to v3.0.4. It now supports setting up HTTP auth per URI pattern, so you can do this nifty trick:

(Note: the auth object goes inside the WebServer object in your config.json file)

"auth": {
	"^/api/app/form": {
		"enabled": true,
		"type": "basic",
		"realm": "Magic Link Form",
		"username": "foo",
		"password": "bar"
	}
}

And viola! You have basic auth for all your magic link pages. Note that you will need to restart the xyOps service for these changes to take effect.

Does this satisfy your feature request?

[talder]

Hmmmm, if i understand you correctly, this is the same user/pass combination for all magic link forms you create? If so, not really i'm afraid. I meant a password/passphrase you can specify per magic link page. (does not have to be user/pass, just pass is ok)

Let me give you an example of my use case. We have a financial department that collect all consults that doctors do and places these in a submap for each dokter. On these folders we set permission that only the doctor can access them, but if there start a new doctor, these maps must be created the first time. For this i created a magic link page where the financial staff can enter the doctor account and his unique practitioners number so the folder can be created. Only the financial department knows the password to access this job/task.

Another department got another link with another password, ec.. so even if they got the link of the financial department, they cannot execute it without knowing the password.

Grts,

Tim

[jhuckaby]

Okay, I see. Well, you can easily extend the web server auth system to support different passwords per each individual URI pattern. Just include the first 8 characters or so of the magic link hash for each of your magic forms. Since the magic link itself is part of the URI, you can use it for routing like this:

"auth": {
	"^/api/app/form/v1/Ylpc0WxY": {
		"enabled": true,
		"type": "basic",
		"realm": "Magic Link Form #1",
		"username": "foo",
		"password": "bar1"
	},
	"^/api/app/form/v1/GpvpxW0l": {
		"enabled": true,
		"type": "basic",
		"realm": "Magic Link Form #2",
		"username": "foo",
		"password": "bar2"
	},
	"^/api/app/form/v1/CQ34DXh4": {
		"enabled": true,
		"type": "basic",
		"realm": "Magic Link Form #3",
		"username": "foo",
		"password": "bar3"
	}
}

You don't need to include the entire magic link URIs, because these are regular expressions that are matching on the "start" of the URI. But you can include the full URIs if you want.

HTTP auth requires both a username and a password, but you can just set all the usernames to something simple that all your departments know, and only vary the password per link, as shown above.

Does this help at all? Or do you need to be able to configure the magic passwords inside the UI when setting up the magic triggers? I can add that to the TODO list if need be, but it will take me a while. That's a large feature build.

[talder]

Ah ok, I see. This will help for now, but maybe in a future release it would be great to implement this in the UI.

[jhuckaby]

Yup, will add it to the list!