Is this possible for my request? I would like to create a un-changaeable or definite (locations and signature) for each user on Lotus Domino..if possible on server-side, I do believe the only was creating a template for each user. Is there a possible way a template but dynamically changes on user logon so that his/her signature will vary also.
Thanks guys..
I would suggest looking at a 3rd party tool, for exampel Crossware Mail Signature.
If I understand it correctly when talking to them (we are looking for a server-based signature system as well), you can set it up so that the signatures are different for diferent users or department, as well as for internal vs external email.
Related
For legal reasons we can't send the email to HIBP in clear text.
Regarding "Domain Search" functionnality, there's no API (as far as I know).
It works by sending you multiple emails, no API, so hard to automate process around that.
I've also read one of Troy's old blog post about a Domain Search callback system he put in place for a specific case : https://www.troyhunt.com/have-i-been-pwned-goes-little-bit/ which looks good but no publicly available (that's my understanding).
So, if HIBP doesn't allow me to do that, I thought of other solutions based on it :
Firefox Monitor and 1pwd :
They use the k-anonymity principle (https://blog.mozilla.org/security/2018/06/25/scanning-breached-accounts-k-anonymity/) which consist to send only a hash of the searched email.
Unfortunately, that functionality is reserved to 1pwd & firefox monitor.
Am I missing a way to interact with HIBP without sending in clear the email ?
Thank you
Short answer: no.
Mozilla and 1Password use the k-anonymity model described here: https://www.troyhunt.com/were-baking-have-i-been-pwned-into-firefox-and-1password/
The reason I don't make that generally available is that every single k-anonymity search returns multiple results which would make it much easier for a nefarious party to abuse. Domain searches require verification of control at the time of search; an API that didn't require verification would also be open to misuse.
If you'd like to see new features, suggest them here (or vote on them if they already exist): https://haveibeenpwned.uservoice.com/
Lets say we have the following url:
https://www.sale.com/?utm_source=CDTest3Newsletter&utm_medium=CDTest3Email&utm_campaign=CDTest3FallSale&utm_id=CDT3ID
A user clicks on the link and surf through it and then close the session.
An hour later he/she navigates to www.purchase.com and a conversion occurs, is there a way to track and relate the conversion to the utm_id=cdt3id?
In Summary the conversion happens in the second domain and we want to relate that to the first domain marketing campaign!
Please note i know hot to enable linker while redirecting from origin domain to target domain!
You have to realize that this kind of behavior is not standard. Therefore, it will require non-standard solutions.
Having said that, your real problem is not the attribution. In the described scenario, you are likely to lose the user completely. Purchase.com will have no idea that this client is supposed to have the same id as on the previous site. The linker adds an explicit _ga query param to the url for the ga library on the purchase.com to know to use that as a user id and not to generate a new one.
If you're not able to reliably pass the client id to the checkout TLD through front-end, you have to use your backend to match the user by the BE auth/session token. Same exact logic applies if you want to pass the attribution data. You just keep it on the backend, bound to the user session token and throw it to the user's cookie on checkout, then grab it with GTM and populate it however you like. Or you can as well just conduct a BE redirect, appending both the _ga and the UTM query params to the url.
There are a bit more options if you're not using GA for your actual analysis. If you're able to match users and calculate attributions on your own either through ETL or persistent derived tables/SQL. So, basically, if you download your GA data to a third party storage like snowflake, asure or BQ and then use a BI tool on top of that. But at this point those options should be pretty apparent from the issue and possible solution described above.
We have a Sharepoint Project Management site up and is active amongst our clients. The site url looks like this:
https://projects.acme.com/clients/[client_name]
Each of our clients has to remember (or bookmark) this long url; the users of this site are not very savvy. They fumble with it all the time. We also do not want clients to know who each other are; so client 1 shouldn't know that client 2 is a client.
We would like to put a login form on our website, prompting for user id and password. Then we would like to be able to route the user based on a successful authentication, to the specific web that is theirs.
Is there a good clean way to make this happen? Is forms authentication the way to go? Are there drawbacks to using forms authentication?
Given my url structure, would this approach work?
http://msdn.microsoft.com/en-us/library/bb975136(v=office.12).aspx
Update: I'm not particularly interested in a solution that requires two weeks of effort on the part of a programmer/admin to setup, nor am I particularly interested in one of the commercial solutions that are $4k-8k. I was hoping to discover a pretty straightforward way to get this done in under a day of effort.
Yes, you can implement it using FBA.
However, if you use only the user ID and the password, the user IDs across all websites will need to be unique (i.e. if client 1 creates a john.smith user ID, client 2 will have to use john-smith or johnsmith or something completely different). The easy solution is to ask additionally for the company name on the login form, the user ID and the password, but then you'll probably have to handle different ways the users will enter the company name (i.e. acme, ACME, Acme, Acme Ltd, Acme Inc, Acme Inc.).
Update:
You can also consider host-named site collections and have URLs like https://client_name.acme.com. The downside is that you cannot use Central Administration to create a host-named site collection - you can do it by using PowerShell or custom code.
Generally it is highly unlikely you will find a free solution to get your task done in under a day of effort - admittedly, SharePoint does support FBA, but does not provide basic things like a login form, a change password form or user management; you need to create them yourself or use some existing solution (e.g. SharePoint 2010 FBA Pack).
If you want to separate users and also make URL's more sweet you have a two ways.
Create a web applications per user.
Create one application with multi tenancy support. Check more on this Spence's Harbar article.
Second approach is more flexible, but harder to implement, and if you plan to have many clients (more than 50) it's the only way.
I am building a Sharepoint web part that will be used by all users, but can only be modified by admins. The web part connects to a web service which needs credentials. I hard coded credentials in the web part's code.
query.Credentials = new System.Net.NetworkCredential("username", "password", "domain");
query is an instance of the web service class
This may not be a good approach. In regard with security, the source code of the web apart is available to people who are not allowed to see the credentials.
In normal ASP.net applications, credentials can be written into web.config and encrypted. A web part doesn't have a .config file associated. There is a application-level .config file for the whole sharepoint site, but I don't want to modify it for a single webpart. I wonder if there is a webpart-specific way to solve the credential problem? Say we provide a WebBrowsable property of that web part so that privileged users can modify credentials. If this is desirable, how should I make the property displayed in a password ("***") rather than in plain text?
Thanks.
Create custom toolpart, check for condition like SPWeb.UserIsWebAdmin, if so, render fields needed for credentials (input textbox, masked textbox etc).
Read the user name and password out of an encrypted section of the configuration file. See https://web.archive.org/web/1/http://blogs.techrepublic%2ecom%2ecom/programming-and-development/?p=448 for more info on programmatic uses.
In addition to the above, you can store the credentials (securely, of course) on the server, be it config file symlinked in, a file in a known location (e.g., common directory) or even (not recommended) in the environment.
A bonus of this method is it allows dev/test/whatever to have different credentials and not interfere with production while developing/testing/etc.
If you want the web part to be independent of other parts of the system, a property is the simplest option. The main downside to that approach is that you can't set permissions for individual properties, so users will see it. You could have the value be a hash (calculated elsewhere by the admin before adding the web part) but I don't think I'd call that a good solution.
If you want to provide ui to admins only, you should create a custom settings page (CustomAction + layouts page) which saves the credentials in a site property, possibly encrypted so that they can only be read by your custom code in the web part and settings page.
Here's the scenario:
You have two seperate websites that exist in different environments (I.E. different databases, different web servers/domains)
You have full control over the code for both sites, but from the above point, they can not directly communicate with each other's database
You must transfer user from site A to site B securely
What is the best way to implement this? Simply sending the user identifier between the sites via query string wouldn't be secure, even if encrypted, since someone else could obtain the URL. It seems like the standard solution is to pass the user identifier along with another temporary key that web site A created, and web site B knows about. If this is the case, what's the proper way of securely setting up the system with the temporary key?
Thanks!
I am doing something like this. The best thing I can think of right now is passing a HASH of the user ID, or if that makes you worry, the hash of some other user data.
If yuo want temporary keys(I might do something like this too), how about setting up a web service on A that B can call to to get the user ID based on the temporary key. This way it's a totally separate call, and can be secured.
Take a look at "Pass-through Authentication," its a concept that allows a user's identity to be passed from one system to another.
Additionally, another idea that you may want to try is to create a secure token that does not expose the user's information and pass it on. However, this requires both systems to have similar data to verify the token. As the other answer suggested, hashes are very good uses to create non-descriptive bits about sensitive information.
Write a web-service call over HTTPS, at both ends, to retrieve the users details, and that only works for a specific login-pair. Problem solved. You need to make the login-id's at both ends uniform or use single sign on cookies. More details in the paper by Vipin Samar: "Single Sign on Cookies for Web Applications".
They can't get the URL/Passwords unless they go into the application code at one of the servers.
You need to pass information between Site A and Site B, but you don't need to make the user the conduit for that information.
Site B could have a web-service that allows Site A to create a session for the user. In this design the interaction would go as follows:
User clicks button on Site A
Site A calls web-service on Site B which passes a temporary login URL back to Site A
Site A redirects user to the temporary URL on Site B