I want to implement user mentions with #username like in Twitter. But, in my app, the username may change. My approach is to parse the post before saving into the database and convert all the #username to #userId. What do you think of this? Does anyone has any better alternative?
Store the original text, as is, and create a table of related records with the uid and username.
Example schema:
post [table]
id
text
user_mention [table]
id
post_id
user_id_mentioned
user_name_mentioned
When a post is saved, your code should go through and create all the user_mention records. You can loop through the mention table to send e-mails or whatever else you want to do.
If the user changes their user name, you now have the option of updating the post with the new username, or having the old username link to the correct user.
My rule is to never, ever modify original unstructured text before saving to the database (but do sanity check it to avoid injections and whatnot) and modify the data only on output. This means you always have the user entered data, and you never know when that will be valuable.
Maybe one day you are interested in who changed their username after being mentioned n number of times? Or some other report that you can't get because you modified unstructured data. You never know when you will want the original data and, in this case, you get the added bonus of having your text easier to work with.
Yeah, I think checking the username list at the post time, and converting them internally to a user ID makes sense. Then, whenever you display the post, translate the user ID back to the current username.
Note that this will be more difficult for non-dynamic content, such as emails sent, etc.
Also, I'd make sure that the usernames are displayed in a way that makes it clear that they're not words the OP posted, otherwise, that would give a way for users to inject text into someone else's post.
Yes I think that is good. Twitter itself doesn't just use Usernames it uses UserIDs.
It gets the tweeters user ID then looks it up to get the the actual username.
Documentation : Mentions and Lookup
Each user should have a unique ID. You should match the ID's with the username before you send it anywhere which would be visible for users.
Related
My doubt is quite simple probably, but as a first time for me, this things get confusing
My PHP code is basically a session based one where each person gets texts to display on their page once logged in, but each person gets different ones, and those are saved on a database with their names too
So I need to know how would I make the query on php to get the information belonging to my current user
Something like
if(user=="John"){
display(documents of John);
}
Of course "documents of John" is a field instead
But, hopefully you can get the idea
Thanks
use the user and run a sql query to get document from documents table where username = user. Retrieve the data.
You got the document related to that unique user.
I am sending a GET Parameter which is an ID, of course this ID is needed to pull fields from salesforce using the soapclient API.
My issue is because this parameter can easily be changed by a user to a different ID, on load of my page it will pull up other fields based on that other ID the user had altered.
How can I secure this in some form? whether it is from the salesforce end or the php side, My Solutions I came up with are the following but I found tedious.
Have a field in salesforce that is ticked if user has submitted the data before so old data can not be viewed again when it does a check to see if it was submitted.
Create a session, grab the get parameter, then redirect to the same page. but that is a bit tedious.
What is the best solution for handling a GET Parameter from a salesforce link that will arrive in a email to the user?
I'm not sure how you generate these ID's or where you use them. But if you store them somewhere and then retrieve them at a later time you could try and hash them. When the ID gets generated either hash it right away and use this hash as the identifier or, if you only get the ID at a later point (on insertion for example), you could create a hash out of the generated ID and store it in a different field of the same record. Later when you are retrieving or showing records to the user you can hash the ID again and make only requests using the hash. This would be a pretty difficult way for the user to get any other records since they would have to know the hash that was generated for the ID.
Of course it all depends a bit on your implementation. I don't have any personal experience with salesforce, so I don't know what might or might not be preventing you from implementing such an idea.
I would like to have a aspect of my site that users can use to sign up for a newsletter.
I am not 100% what the best way to accomplish this task would be.
What I can think of is very simple:
One input with a submit button, the user enters their email address there.
A random 32 character hash is generated and stored along with their addess within a mysql table.
Am email is sent to the address containing the hash and asking the user to enter their email address and the hash on a page that checks it against the mysql table.
If correct the email becomes active by defining an additional entry on the table.
That is about as far as my knowledge of the two can take me...
What i would like to accomplish, is in the confirmation send the user a link that they can click to confirm their address... something like http://www.mysite.com/users/newsletter/?user=aGuy&confirm=blahBlah.
But I really do not know where to start with something like that... And as i understand it, allowing mysql queries in such a manner is not secure...
Would someone be able to provide me with some more information regarding this matter?
This being in the form of suggestions or links to tutorials that may cover something like this.
Thank you for taking the time to read this!!
You're close.
When a user submits his email address, insert it into the database. At a minimum, the table should 4 fields (id,email,verified,key). The id is just a surrogate key (auto-increment). verified should default to false, and the key shouldn't really be a hash but a randomly generated string -- anything that's hard to guess. Hashes are deterministic, so hashing the user's email address with an md5 wouldn't make for a good key if someone figured out what algorithm you were using. A random element is better suited, but again, anything hard to guess will serve just fine.
The email should contain a link that holds the id and the key. You use the id to look up the record in the DB (since it's unique) and then check that the key in the URL matches the one stored in the database (key doesn't have to be unique). If they match, set verified to true, and voila.
For bonus points, you can store a date that the verify email is sent, and you can prune out unverified emails after 24 hours or so.
Your description of the flow is fine, just start implementing it.
The sfGuard package implements a similar flow, check out their source code and database design.
I have a site where users must confirm their e-mail using a typical e-mail confirmation script with a specific (but long) Confirmation Link for each user that includes the usual hash parameter.
The problem I'm having is that some users are having problems with the long and complicated Confirmation Link due to the device they are using.
So I need to create an alternative way to generate the unique Confirmation Link for each user such that no pattern is obvious so that it cannot be figured out and abused.
I've been looking at Base62 encoding and decoding, but the one I found is based on numbers only, which would limit me to using the sequential unique User ID's, which then creates an obvious sequential pattern in the encoded results which could easily be abused.
Preferably, I want a solution that will not require me to alter the DB.
Ideally, I would like to basically create a shortened URL similar to how Bit.ly and other url shorteners create their unique URL's, but that can be encoded and decoded either off of the User ID, username, or e-mail, and preferably have the encoding/decoding "salted" with a unique key so that no pattern emerges in the encoded results.
EXAMPLE:
So instead of the confirmation link looking like:
http://domain.com/confirm?email=blah#blah.com&hash=1f3870be274f6c49b3e31a0c6728957f
I would like it to look like:
http://domain.com/confirm/Sg5rdn
Where I would then simply decode Sg5rdn to get the Username, User ID, or E-mail of the user and confirm them.
Is this even possible?
Instead, just create a table with confirmation codes. When a user should do a confirmation, create an unique code (using base62 or whatever), insert it into that table and assign it to the user id.
Then, when the user hits the confirmation link, just fetch the user id etc from the confirmation code table (and check that the code exists and still isn't confirmed etc).
I would suggest you store the code in a column in the user table:
example table very shortened:
id--user---email--------------key-----confirmed----other stuff
1 bob bob#example.com 1h323f 1 ...
2 rob rob#example.com 18gg3f 0 ...
3 steve steve#example.com a862gf 1 ...
4 tom tom#example.com 17g23f 0 ...
As the user signs up for an account pre create the key and store it along with the username ect
Then when the link is clicked check for the key against the email, then update the confirmed to 1.
You could use .htaccess on the link to make it even shorter:
RewriteRule ^confirm/(.*)/([a-zA-Z0-9]+)$ confirm.php?email=$1&hash=$2 [L]
eg:http://domain.com/confirm/tom#example.com/17g23f
Hope this helps
I'm afraid your expectations a bit exaggerated.
The only thing you can really do is to shorten a hash a little.
the only way to "decode" Username, User ID and E-mail out of Sg5rdn is to fetch them all from the database.
Working on a web based "buying and selling" application with PHP MySQL where users can post adverts for items and services.
Before a new advert is displayed on the system there must be a method of verification to ensure that the user provided email address is correct, and that the advert is legitimate.
I want to send the creator of any new advert an email containing an url which directs to a page whose primary functionality is to receive a posted variable, $advert_id, and to select the advert from the db for updating / editing / deleting.
This variable is embedded in the url with PHP syntax
ie. [http://www.example.com?content=modify_advert&advert_id=2246317].
This part is quite simple to implement, BUT, if a user was to modify this variable called "advert_id=2246317" to any other integer, they can access other posts/adverts in the system.
The system is advert based, and users dont need an account or login to post, so we cannot prompt for a login at the point of verification which would have been convenient.
Any ideas as to how we could protect the adverts/posts in the system from being accessed via the aforementioned url???
Any suggestions?
If visitors will only be viewing that page from the link you send via e-mail, you can include a hash in that address instead of the advert_id — essentially a random, one-time password.
One common and "often good enough" trick for generating such a random password is to take a single, secret, truly random string (I usually use grc.com), concatenate it with the unique advert_id, and hash the whole thing with, say, SHA1(). Like so:
UPDATE advert SET advert_hash = SHA1(CONCAT(advert_id, 'lots-of-randomness-here'))
You could even vary this by adding time(), or (better still) a random number to the end. The outcome is a 40-character string stored in your database that nobody could possibly predict (without knowing the secret data you used to generate it).
For example, I might get this instead of advert_id=1:
f2db832ddfb149522442c156dadab50307f12b62
If I wanted to sneakily edit advert_id=2 (which somebody else created), I'd first have to guess that the hash is this completely different string:
e5c6a3a9473b814b3230ee7923cbe679fcebc922
So, include that in the URL instead of the advert_id (or, if you like, in addition to the advert_id), and suddenly your users are powerless to ruin other people's content.
You could add a salt to the id and then hash it.
sha1($advert_id . $salt);
Send this to the user in the URL instead of the advert_id, and store it in your database, along with the advert_id.
Then when they click the link, you find the matching advert for that hashed value.
Making the salt a secret is how you keep users from 'guessing' a valid URL that will let them modify an ad that they did not post. Perhaps you could use the users email address, the time posted and/or a name or something that the user enters when they make a post.
Generate a GUID as the advert ID so simple ID guessing attacks are unlikely to succeed.