Which database table or tables record signature limits -- max characters, number of images, image width, etc?
Table: settingsValue: signature_settings
Settings are separated by a comma. Just fiddle with the individual settings in the admin panel and see how they change in the db entry. I think the format might be in the order you see them on the admin settings page. I know the first entry is a 1/0 value describing whether signatures are enabled or not, and the 2nd value is the max signature size.
I have to ask, why does it matter?
also...... though it may be a matter of approach, it's my opinion (fwiw) this is better handled with CSS - especially if there are existing signatures that will be impacted.
something like:
.signature {width:99%; height:1em; margin: .25em auto; overflow:hidden;}
.signature img{ max-width:300px; height:auto;}
for users this impacts, it will put the burden on them to make it look good instead of you toying with things in the db that has opportunity to jack things up.
Thank you, VirginiaZ.
To the others: Why do you assume I intend to change those values? Could it be that I need to read those values? :)
If you need to read them, go to the settings page where.
If you're trying to read them for some other purpose, knowing what that purpose is would help us help you (since doing DB queries for something likely already loaded and available is a bad idea)
I'm working on a mod that needs to read them into its PHP script. I would think the system would not allow a mod to change those data unless the logged-on user had admin permissions. Thanks for your comments.
You'd be wrong about that, which is why I ask what you're trying to do and how.
I'm not trying to be evasive, just trying to avoid you wasting time in incorrect ways of doing things.
Wrong in what way? Is there another method other than reading the database for a mod to determine at run time, for example, the maximum character width of a signature and the maximum image dimensions?
Yes, there is, but again it depends on what you're trying to do and exactly where!
Most likely I'd be suggesting to examine the global array $modSettings, which contains all the settings, but honestly I'm finding it hard to help you do it correctly and efficiently.
https://wiki.simplemachines.org/smf/Global_variables
What I'm trying to do and exactly where:
I am writing a program that runs independently of the SMF source code except that it has access to Settings.php only to have the $db_ variables defined. The program needs to read the signature settings. That's what I'm trying to do.
Thanks for the mention of $modSettings. I didn't know about that so I went poking around. Its values are defined in the database and retrieved in Load.php. I'd have to get deep into SMF to use it. At the time my program is running, SMF is dormant. SMF launches the program then stands by while it runs.
It's just easier to get the signature settings directly from the database. I wish to keep my program independent of SMF (other than the database) since the program runs on other platforms and on its own. I can hear the next question coming. How can I be independent and still access the database? I cannot, but that's a longer story than this one turned out to be. :)
Quote from: Aleksi "Lex" Kilpinen on February 07, 2019, 12:30:02 PM
https://wiki.simplemachines.org/smf/Global_variables
Thanks, Lex, for the link.
No, the question isn't 'how can you be independent and still access the database'. The question is, what you're going to do with that, presumably you're creating a profile page outside of the forum that users can edit and you want to synchronise the two. The problem you have there is good luck to you to sanitise the signature in a way that won't give you security holes coming back into SMF afterwards.
Suggestion: include SSI.php rather than Settings.php, this will give you a DB connection and access to core SMF functionality (including having $modSettings be loaded for you automatically, which will also benefit from caching if suitably configured) which means you can then load the relevant security routines you'll need.
Thanks, all, for your help, comments, and suggestions. I have what I need to proceed.
Oh dear.
Lest anyone gets too concerned, know that I am spending the next couple of days poring through SSI.php and the $smcFunc docs as per Aruntor's suggestion. Interesting stuff. I'll return as questions arise. I've seen some syntax that I don't recognize, which is to be expected.
Aruntor has been adamant about learning what I am building. That will come later. In the meantime, the only SMF site where I have installed my program is on a private wamp server. No one's database is at risk except for mine, and it gets initialized frequently. The test forum has only two users and I'm both of them. Later, the program will go onto a public server, also mine. An early version is there now, but not integrated with an SMF site.
Thanks again for all the help and in advance for that which is to come.
I've been adamant about trying to protect you from opening up security holes, but you seem sufficiently insistent that I'll leave you to it.
Quote from: Arantor on February 08, 2019, 06:09:40 PM
I've been adamant about trying to protect you from opening up security holes, but you seem sufficiently insistent that I'll leave you to it.
As well you should. But you'd have no way of knowing that.
Don't get us wrong, Arantor simply knows the code better than many others around here, including me, and with things like this it is easier for everyone to provide answers when you know exactly what the question is.
I have no way of knowing it, no, but I have a fair suspicion.
Consider from my perspective, I learn the facts as I have them, that you're building a page outside of SMF and that you're just inheriting the DB connection (for now), and you're showing setting values that only make sense if you're letting a user edit something in a user profile type page.
On the one hand, if you're doing it for the current user and not using SSI, you have to work out the current user, which means decoding the current session, implementing your own code to actually interact with SMF code, not have session fixation bugs while you do it, and then when you get to doing any changes, roll your own CSRF handling, make sure to avoid SQL injections and save a signature whilst protecting against all the things that could go wrong with sanitising that. (Doing that correctly without SSI is sufficiently difficult that I, as a 16 year veteran of PHP, ZCE and former dev team member of SMF, wouldn't want to attempt it. Unsanitising again safely for the editor, assuming using SMF's editor, is borderline impossible without deep knowledge of everything related. Not using SMF's editor, even more difficult.)
Then it occurs to me that you could be using a framework. That would give you session handling and CSRF protections (depending on framework, not that it would be compatible with SMF session handling), and likely even SQL injection protection, but good luck hooking that up to SMF to connect up SMF's security around content handling.
This is all assuming you're still pushing signatures through SMF and that users can edit them in their profile. If not, a whole different set of ball games can occur in terms of what the profile code could do about whatever content you add to the user profile, to the point you'd have to strip out most of the user profile stuff to actually be safe about it. (And disabling the profile permissions might not do what you need it to, either)
And then change how signature loading is done.
The part that suggested to me that this might be "difficult" was when you suggested that settings could only be editable by admins. Firstly that's not true anyway, as you can give parts of the admin area to non admins, and secondly, updateSettings() makes no such checks because there are plenty of times inside SMF where non admins do things that trigger that anyway, which to me suggests a lack of familiarity with the code, to the point where I'm not convinced currently you'd implement what I think you're trying to do safely.
You're probably thinking "it's just a signature, what's the risk", but with the vulnerabilities I can consider from this, I could fairly trivially hijack accounts, including admin accounts. And on a standard SMF install, this means I can escalate to complete site takeover and running literally anything I want on your server. I'm not exaggerating, I'd use exactly the same techniques as were used against Avast's SMF installation, which as currently described, is still possible.
But sure, dismiss me as a nosy busybody if you must. You seem to know best, after all.
Quote from: Aleksi "Lex" Kilpinen on February 09, 2019, 01:03:14 AM
Don't get us wrong, Arantor simply knows the code better than many others around here, including me, and with things like this it is easier for everyone to provide answers when you know exactly what the question is.
The question was, where in the database are the signature limit values stored. I'll explain in a while why I needed to know that since it has generated some apparent concern. But Virginiaz gave me the answer right off the bat. Everything that followed has been helpful, but my immediate problem has been solved.
Thank you for your comments, Aruntor. Here's a summation of my project.
Some SMF sites, specifically those for book authors and readers, include what they call "link-makers" that assist users in compiling BBCode, which the users paste into their signatures. www.kboards.com is an example.
The complex part of those tools are their use of the Amazon PAAPI search engine. My task is to improve on the search engine interface so that, for example, an "author" search for my name returns only my titles rather than the bazillion others the generic keyword search returns, which is how the link-builders I've seen work and how Amazon's product page works.
There's a lot more to it than that, but that's probably more than you wanted to know.
The program will use the signature limits from the database to validate the BBCode signature it compiles and to adjust the sizes of images.
A bug in the SMF signature code causes image sizes to enlarge when you click on them if the src image is larger than the maximum height/width allowed. (You can see that by clicking the book cover I put in my signature here. Re-click back here to see that the cover got bigger.) One admin I spoke with says he gets lots of messages about that from his users who think he can fix it.
The cover image files for Amazon books are always a lot bigger than what some signature limits allow.
A program that knows these limits can use a more intuitive way of telling a technically-challenged user what's wrong. Besides the limits, the program needs to know which BBCode tags are disallowed. Stuff like that.
Maybe all or some of this has been addressed in mods. I don't know. My task is to build a tool to spec.
I don't know whether that's enough of an explanation to suit you. I don't want to turn this discussion into a debate about the need for such a program--I'm merely the programmer--and I had to let others know that I would be discussing the project publicly. Kind of like "executive privilege." :)
As far as knowing the user that launches the tool, I found that these variables provide those data:
$user_info['id']
$user_info['username']
They can be passed to the program when it's launched.
With the id, I can paste the compiled BBCode into the signature for the user, which might be better than having them do it themselves. You say "BBCode" and "clipboard" to the typical romance author and you get a blank stare. :)
I tried this and it works.
"UPDATE {$db_prefix}members SET signature = '{$bbcode}' WHERE id_member='{$userid}'"
although it should probably use the $smcFunc function array for that.
Quote from: Al Stevens on February 09, 2019, 10:22:57 AM
www.kboards.com is an example.
Question: What is the [nofollow] tag after that link. Is there a way in BBCode to suppress it in a signature? See my signature for an example.
Quote from: Al Stevens on February 09, 2019, 10:40:38 AM
Question: What is the [nofollow] tag after that link. Is there a way in BBCode to suppress it in a signature? See my signature for an example.
it's a mod, not a default feature in smf
Quote from: Al Stevens on February 09, 2019, 10:22:57 AM
A bug in the SMF signature code causes image sizes to enlarge when you click on them if the src image is larger than the maximum height/width
that's not a bug, it's a feature. Maximum height/width can be edited from the admin panel
Quote from: SychO on February 09, 2019, 10:48:02 AM
it's a mod, not a default feature in smf
Could you point me to that mod? I don't know my way around all of them. Thanks.
Quote from: SychO on February 09, 2019, 10:48:02 AM
[quote aQuote from: Al Stevens on February 09, 2019, 10:22:57 AM
A bug in the SMF signature code causes image sizes to enlarge when you click on them if the src image is larger than the maximum height/width
that's not a bug, it's a feature. Maximum height/width can be edited from the admin panel
Changing those values has no effect on the behavior. It's a bug.
I wasn't interested in whether it was needed or not, that part I assumed was fine. I was concerned with how fixated you were on the methodology of implementation. Like how your current SQL might be ok assuming you validate everything coming in and make sure you never build links with untrusted user content. Otherwise your method will bypass every single security measure. In fact you still might have trouble depending on exactly what content you insert there given that it explicitly bypasses every sanitisation routine.
As SychO says, the resizing of images over a certain size is a core feature but not necessarily of images in signatures, it can also be the default limit on images in SMF too.
Personally, I'd change the settings not to limit image sizes at all at the SMF level (not a bug, just configured differently to how you think it is configured), and just use CSS to fix a maximum size in posts (and thus not touch signatures, so they can be whatever size you care to let people have, and alternatively have a second size rule on signatures done in CSS totally bypassing SMF's size limits)
Assuming you implement that, what else needs doing?
Quote from: Arantor on February 09, 2019, 11:21:23 AM
As SychO says, the resizing of images over a certain size is a core feature but not necessarily of images in signatures, it can also be
I understand that. But click on my image and then return here with the <- button or closing the window/tab it opens. The image in the signature is now larger than it was before you clicked it and went to the link. Not a lot larger in this case, but if my src image was huge, it would be here too irrespective of the width property in the BBCode or the limit value that the admin sets. But only after you've clicked and returned.
If that's a feature, I wonder about its purpose.
Its purpose is an interrelation of two separate features.
1. A link wrapping an image.
2. An image whose size is constrained that will have JavaScript to resize it.
If you don't put it inside a link, it *still* does the resizing thing, exactly as it is meant to. You have two separate behaviours that are individually functioning exactly as designed - it's the combination of them that isn't working exactly as designed, at least now. 15 years ago browsers handled this a little bit differently, which is how old a lot of that code really is, and the activation of the link prevented the other JavaScript running but browsers multi-thread this now (slightly against the original spec, I might add)
I still wouldn't argue it as a bug, even though it's clear you feel differently.
However, I guess you're too fixated on what you think you see to notice that I already told you how to prevent this *entirely* by changing the configuration and tweaking the theme to handle it differently. You'd use max-width and max-height CSS directives now to solve this; things that simply didn't exist in 2003 when this was originally written or in 2007 when it was updated. These weren't supported by the then-dominant browser, IE, until 2009. This period completely predates the entire existence of Chrome for some historical context.
Also, there *is* a bug in the img bbcode in 2.0 whereby the entire size of the image can be completely bypassed but that's been fixed in 2.1. (This is another reason I'm trying to be very careful about what advice you get, so as to minimise breakage when the inevitable upgrade happens.)
Thanks for the explanation. Now I must fixate on my own bugs. No doubt I'll be back with more questions.
I asked earlier about the unpaired [nofollow] BBCode tag that SMF adds to links in messages and signatures.
For example: https://www.alstevens.com (https://www.alstevens.com)
Is there a way to suppress that display? I don't care about messages, but I'd like to suppress it in signatures. I looked at the mods that are listed under a nofollow search. They add the rel="nofollow" property to the compiled link. Is the [nofollow] text a byproduct of one of those mods?
I will reiterate what was said above. It is a mod used on this site, it's not standard in SMF - the one used here is a slightly modified form of https://custom.simplemachines.org/mods/index.php?mod=2404
Stock SMF does not do this.
Your reiterated explanation includes a link to the mod, which I'd asked for but didn't get before. Thanks. I opened the source that it generates and can see what it's doing. That [nofollow] that gets added to the signature explains in its mouseover title why it has been added. Maybe it goes away after I have 25 posts. I hope I don't have that many more questions. I'm sure you do too. :)
It goes away *here* after 25 posts. But *here* is not the same as whatever site you're actually working on, I would certainly not take anything this site does as a baseline as I'm aware that's there's a significant amount of changed code.