I've tried to add a new user with phpmyadmin of my host but it didn't work. After I
add a new record in user table (same of other users info) and tried to login with
my new username to the MediaWiki, the system said user doesn't exist.
Don't touch the database manually, if you need to do this server-side, there's a script for that called createAndPromote.php in maintenance/.
If you want to import many user at a time ,you can use ImportUsers extension, it allows you to import a CSV file (with user list) into the system.
You can not insert records in User table for it has a password field which being encrypted by a PHP function.But for other tables like tw_group or user_groups,you can change it directly in database.
Was evaluating BlueSpice (based on MediaWiki) and came to that point, too.
Problem in my case was: In table user, column user_name, entries must have capital first letter! E.g.
|user_name|
|test |
is not working.
|user_name|
|Test |
is working.
Also, regarding the "password" problem mentioned in the other answer: You can create it by yourself. Here's a quick and dirty solution using some webtools.
Create random hex for salt (32 bit)
https://www.browserling.com/tools/random-hex
Turn salt to base64
https://base64.guru/converter/encode/hex
Create key from password (30000 Iterations; dkLen 512; PBKDF2WithHmacSHA512)
https://8gwifi.org/pbkdf.jsp
Create Key String (replace >>XX<< with the values from above)
:pbkdf2:sha512:30000:64:>>SALT_IN_BASE64<<:>>KEY_STRING<<
Ps: For the user_token I used a random 32bit hex.
Be extremely careful when making direct changes to the database. Always test extensively. This is not for newbies who copy from StackOverflow without understanding what they are doing!
Related
After testing and ensuring my Send_email function authenticates successfully using the hardcoded user and password in the SQL Table, I am now trying to Hash the password.
the way my columns are set up is something like this:
variable | value
password | someP#ssword
the columns are varchar both, with the value column being 1000 length (is that too much? i set it to that much cause i read that sha 512 requires a lot of length or something, and seen examples using 1000 at least so went with that)
I am using this query to hash,
INSERT INTO [dbo].[Table] (value)
VALUES(HASHBYTES('SHA2_512', 'someP#ssword'))
but it generates a nonbinary hash, which i am suspecting is why i am receiving this error of email authentication failed because it probably cant decipher the nonbinary password characters. but the problem is i have other values in the value column, so i can't convert the whole column to varbinary.
so is there a way to hash the password that is hardcoded or i have to insert it as hash? or is there a way i can convert just that particular field/cell without having to alter the rest of the design of the value column so it wont affect other values in there as well? or am i supposed to create a completely separate column for password and set it to binary?
EDIT: I have to pass the password in this email function call for authentication:
Send-EMail -EmailFrom $From_Email -SendTo $To_Email -Body $Email_Body -Subject $Job_Success_Email_Subject -Username $SmtpUser -Password $SmtpPassword
but Von in the comment said i can't pass the hashed password in there as credential. then that means i have to keep it nonhashed in the table? i thought hashing would work perfectly in this situation...
It looks like you have been confused by the irrelevant discussion in the comments above.
First of all: hashed password would not work in your Send-EMail function as the function has no way of "unhashing" said password. Read this introduction to Hashing vs Encryption.
If you want to secure your password and be able to retrieve original value you will need to encrypt it. The topic of encryption is quite large and way outside the scope of what can be written in SO. I will provide a few links for you to read:
http://www.manjuke.com/2018/03/data-encryption-in-sql-server-using-t.html
https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/encrypt-a-column-of-data?view=sql-server-2017
https://learn.microsoft.com/en-us/sql/relational-databases/security/encryption/sql-server-and-database-encryption-keys-database-engine?view=sql-server-2017
Encryption by pass phrase would be the simplest to implement but also weakest as anyone reading the code of an SP will find out the pass phrase and therefore can decrypt data. Note that pass phrase itself can be passed into ENCRYPTBYPASSPHRASE as a parameter, allowing you to store it (securely) elsewhere outside the database i.e. you don't have to hard code in your SP code. You will need to implement pass phrase storage method yourself if you decide to go this way.
Encryption using keys and certificates offers a very secure method but requires some time to set-up in addition to very carefully backing up your keys. If you loose your keys your data is gone i.e. you can never decrypt it.
As far as storing binary data in varchar column goes - easy, here is an example:
DECLARE #BinValue VARBINARY( 500 ) = HASHBYTES('SHA2_512', 'someP#ssword')
DECLARE #StringBinValue VARCHAR( 500 ) = CONVERT( VARCHAR( 500 ), #BinValue, 1 )
SELECT #BinValue, #StringBinValue, CONVERT( VARBINARY( 500 ), #StringBinValue, 1 ) AS BackToString
I have used your original HASHBYTES function as an example but you will need to change it to an encryption function.
Hope this clarifies things for you.
So I want to create a database link in oracle, my username is jefferson and I want to connect trough opms so I was told to do this.
create database link tmpp connect to jefferson[opms] identified by nothing using $something ;
For some reason when I try to use [] syntax it just tells me indentified is missing. Why is this not working, I was told to do it this way but I can't find any help in the official documentation for [] usage or the correct syntax.
You can create a fixed-user database link like this, but you need to enclose the entire proxy user identifier in double-quotes; and because it's now a quoted identifier the case has to match the DBA_USERS username, which is uppercase by default:
create database link tmpp connect to "JEFFERSON[OPMS]" identified by nothing using ... ;
As noted in MOS document 1477939.1 you can't create a connected-user database link (which you aren't trying to do); and the 30-character limit on identifiers applies, so the total length of both usernames plus the square brackets has to be 30 characters or less (which is also fine in your example).
However, as discussed in this related question, this functionality is currently broken in 11.2.0.4 and above because of bug 19191702.
I have created a local table and inserted some data. As long as I don't use is secure for fields all works fine. But when I use is secure for some fields I only get encrypted text for these fields. It seems that a decrypt function is missing. How to solve this?
For accessing the fields I use:
var field_value = Data.execute("select f3 from Testtable where rowid = 3;");
alert("Row 3:" + field_value);
Actually, you should get encrypted values if you try this kind of sql execute statement, regardless from how many rows are selected as isSecure.
I mean, if there is an isSecure field, it should always be seen as encrypted. Selecting some rows as inSecure or all of them as inSecure, shouldn't change anything.
The new release of Smartface App Studio is available right now.
(http://account.smartface.io/Account/Login?ReturnUrl=%2F )
I tested your case, it works fine with this new release.
By the way, if you want to reach the actual value in table, try the below code :
Data.myDataset.move(2); //Lets reach the same row you wrote above with move
alert("Row 3 : " + Data.myDataset.f3);
You should write your dataset's name instead of myDataset.
I've been assigned the task of creating a table that stores an email signature for each username. The question is, how should I store the signature block? I could use a regular varchar type, but then how do I store the formatting metadata?
Any ideas or suggestions would be welcome.
Thanks!
Another idea I had was that you could design a specific email signature template, and then let people specify fields, such as Username, quote, avatar, alignment etc, and then have them modify their signature in a "signature editor". This way you could just store the "data" and not the rendering. so you could store something like follows:
<signature>
<username>chama</username>
<avatar href="http://url to my image"/>
<quote>A bird in the hand is not in the nest</quote>
</signature>
and it could look something like:
Chama
A bird in the hand is not in the nest
use varchar(max), or whatever length limit is appropriate.
otherwise, the only real concern is that you might want to make sure the html is html-encoded before you stick it in the database. (i.e., replace < with <, etc.) Not sure what you're using, but some tools have a setting so you don't have to do it manually.
other things you can do besides / in addition to html-encoding
1) restrict the formatting tags to some pre-defined set (i.e., search/replace tags you don't want before doing the insert. You can manage this in your db stored procedure, or better yet, in your front-end (if you have control over that).
2) disqualify attempts to insert data if they include certain tags (like '<script>', etc.)
HTML, RTF, XML. The stanard choices are multiple.
Note: "email signature" is NOT "digital signature". The term digital signature has a specific meaning and means a SIGNATURE to make sure - for email - it comes from th real sender and has not been tampered with.
I'd suggest going with your initial thought -- varchar(max). This will allow you to store signatures that are ASCII based. This includes plaintext, RTF or HTML signatures.
If users want to embed images (i.e. not a link to an image), then you'd have to determine a way for the caller to convert those images to Base64 or other before storing and after reading from your table.
Based on what I'm finding, you have basically two options:
1) Convert your formatted signature data to Binary and store it as a BLOB.
2) Instead of saving the signature itself in the DB, save them as files somewhere and store a reference to that file location in the DB.
I'm adding a field to a member table for twitter names for members on a site. From what I can work out the maximum twitter name length is 20 so it seems obvious that I should set the field size to varchar(20) (SQL Server).
Is this a good idea?
What if Twitter starts allowing multi-byte characters in the user names? Should I make this field nvarchar?
What if Twitter decides to increase the size of a username? Should I make it 50 instead and then warn a user if they enter a name longer than 20?
I'm trying to code defensively so that I can reduce the chances of modifying the code around this input field and the DB schema changes that might be needed.
while looking for the same info i found the following in a sort of weird place in the twitter help section (why not in the API docs? who knows?):
"Your user name can contain up to 15 characters. Why no more? Because we append your user name to your 140 characters on outgoing SMS updates and IM messages. If your name is longer than 15 characters, your message would be too long to send in a single text message."
http://help.twitter.com/entries/14609-how-to-change-your-username
so perhaps one could even get away with varchar(16)
While new accounts has a limit of 15 characters in the username and 20 characters in the name, for old accounts this limit seems to be undefined. The documentation here states:
Earlybirds: Early users of Twitter may have a username or real name longer than user names we currently allow. This is ok until you need to save changes to your account settings. No changes will save unless your user/real name is the appropriate length; this means you have to change your real name/username to meet our most modern regulations.
So you are probably better of having a long field and save yourself some time when you hit the border cases.
Nowadays, space is usually not a concern, so I'd use a mostly generic approach: use nvarchar(200).
When designing DB schemas you must think 2 steps ahead, even more than when programming. Or get yourself a good schema update strategy, then you'll be fine also with varchar(20).
Personally I wouldn't worry. Use something like 200 (or a nice round number like 256) and you won't have this problem. The limit then is on their API, so you might be best to do some verification that it is a real username anyway. That verification implicitly includes the length checking.
Twitter allows for 140 characters to be typed in as the message payload for transmission, and includes "[username]:" at the beginning of the SMS message. With an upper limit of 140 characters for the message combined with the messaging system being based on SMS, I think they would have to decrease the allowable message size to increase the username. I think it is a pretty safe bet that 20 characters would be the max username length. I'd use nvarchar just in case someone uses 16-bit characters, and maybe pad it a little. nvarchar(24) should work; I wouldn't go any higher than nvarchar(32).
If you're going to develop an app for their service, you should probably watch the messages on Twitter's API Announcements mailing list.
[opinion only]
Twitter works on SMS and the limit there is something like 256 characters, so the name has to be small to avoid hitting into the message.
nvarchar would be a good idea for all twitter text
If the real ID of a Twitterer is a cell-phone then the longest phone number is your max - 20 should easily cover it!
Defensive programming is always good :) !
[/opinion only]
There's only so much you can code defensively, I'd suggest looking at the twitter API documentation and following anything specified there. That said, from a cursory look through nowhere seems to specify the length of the username, annoyingly :/
One thing to keep in mind here is that a field using nvarchar needs twice as much space, since it needs 2 bytes to store each potential unicode character. So, a twitter status would need a size of 280 using nvarchar, PLUS some more for possible retweets, as those aren't inlcuded in the 140 char limit. I discovered this just today in fact!
For example:
RT #chatrbyte: here's some great tweet
that I'm retweeting.
The RT #chatrbyte: is not included in the 140 character limit.
So, assuming that a Twitter username has a 20 character limit, and wanting to also capture a ReTweet, a field to hold a full tweet would need to be a nvarchar of size 280 + 40 (for the username) + 8 (for the initial RT # before a retweet) +4 (for the :+space after a Retweet username) = 330.
I would say go for nvarchar(350) to give yourself a little room. That's what I am trying right now. If I'm wrong I'll update here.
I'm guessing you are managing the data entry on the Twitter name field in your application somewhere other than just in the database. If you open the field to 200 characters, you only have to change the code in one place or if you allow users to enter Twitters names with more than 20 characters, you don't have to worry about a change at all.