It's the first time that I have had to set up a MediaWiki site and I am relatively new to it as a whole.
My problem is that users can upload files (only images in my case) without selecting one of the licenses in the drop down box on the Special:upload page, I have defined licenses though under MediaWiki:Licenses so there are licenses select-able. I would like the upload warning function to tell users that a license is required to upload a file (the same way you are warned the name is to short or whatever). The user must first pick a license before being able to continue.
I have searched around quite a bit and it doesn't seem as easy a changing a variable somewhere. If the solution is something that I should have known I apologize for posting a stupid question...
Well, I've not checked again but this is not really possible with MediaWiki:Licenses alone IIRC. You can however easily set MediaWiki:Licenses to that the default/fallback "license"/tag is something clearly bad like {{DELETEME}} and then set up an AbuseFilter rule to prevent the upload in question. AbuseFilter is very useful, so I recommend trying it anyway.
Alternatively, you can install the UploadWizard, which is very cumbersome to configure but is quite good at enforcing Wikimedia-specific habits like template/copyright paranoia. ;-) Then you can set $wgUploadNavigationUrl to point to UploadWizard, or even restrict Special:Upload visits to privileged users.
Related
A lot of web3 websites are emerging were we need to have, for example, a nft of a given collection to access some subpages of a web app.
But I don't understand something. Since we have the code of the web app, could someone just download the html source, remove the nft check, in that case, and access the subpage?
I know that it isn't that simple to modify an app, especially if they use something like React, but would that be feasible?
I guess not, otherwise they won't do it like this, but I don't get why it isn't possible.
Theoretically, yes they could. Any code that is written on the client-side can be tampered with. If the code on the client-side contains the information necessary to display a particular element, then from a security standpoint, you could assume that someone who's interested enough could reverse-engineer the code and force that element to display, even if you have JavaScript checks that are intended to block it.
The best way for such an application to actually stop important data from being displayed to the user is to only send the data once the server validates that the given user has permission to access something. If the data never gets sent to the client to begin with, and the server is secure there isn't really anything they can do about it.
Another way is to make it more difficult for clients to reverse-engineer the code, by minifying the code and having a whole lot of it. Minified code is very hard to read. For example, it could take quite some effort to read through 6000 lines of minified code and figure out enough about what's going on to make the changes you want. (Someone may get lucky and happen to stumble onto something close to the listeners they can see attached to elements on the page that gives them what they want - but they may not.)
In general: don't trust anything done on the client-side. The only way to be absolutely certain that data isn't displayed to those who shouldn't be able to see it is to never send it to the client in the first place.
I am a student at a University. With the placement process going on, we have an internal placement website that shows updates and status about various companies I have applied to. Since the number of companies is too large it becomes cumbersome to scroll through the complete list to find information. Sometimes, I just miss some things. Now, to tackle this problem, here is what I want to do:
The data is in an HTML table. Each row shows information about one company: Some dates, Status(Not/Shortlisted/Applied), Some yes/no options etc. each in a different column. Once I open the page I want to be able to extract information about which companies I got shortlisted in, and in which ones I didn't make it.
What is the right technology to do this ? I am thinking of writing a Greasemonkey user script (I have never actually written any, but how hard could it be ?). What other options do I have?
Edit: I don't quite understand why this question has voted to be closed?
I just displayed a use case for something general: On opening a web page, automatically extracting information from the page and display it to the user. What is the easiest and sufficiently powerful way to achieve this?
Since you can't get access to the website's database, Greasemonkey would be your best automation approach. However, this task is likely to be over before you can get a decent script up from scratch.
Your best practical approach is to save the pages and/or copy and summarize the data in MS Excel, or equivalent.
~~~~~~~~~
Here at SO, We will not develop any but the simplest Greasemonkey scripts for you from scratch (unless they are fun somehow ;) ). But, you can sometimes get such help in the "Script requests forum" at userscripts.org.
In order for someone to help you, they will need:
A clear idea of exactly what data gets manipulated, and how.
Access to the target site. Or access to saved snapshots of the target pages. GM scripts are extremely dependent on the details of the target page.
"other option":
ctrl + F
enter shortlisted
enter
ctrl + G <--repeat last search
I'm wondering if there are any best practices for organizing files on the filesystem for a site that centers around users uploading files. (Not a hosting site like Imageshack, more like addons.mozilla.org)
Or am I over-analyzing this and should put everything in one folder?
I tend to think about user uploads as just another kind of user data, and so it all goes into a database. Obviously, make sure the database you are going to use for this is a good choice for that, for example, a SQL database isn't necessarily right.
If it makes sense, I try to use a url pattern that makes sense in the context of the usage pattern of the site, for example:
example.com/username/users_file.jpg
If there's just no obvious way to do that, and I have to use a surrogate key, I just live with it:
example.com/files/abc123
example.com/files/abc123/
example.com/files/abc123/users_file.jpg
All three are the same file. in particular, the abc123 is all that the app needs to look up the file, the extra bit at the end is there so that browsers get a good hint at what the file should be named when it's saved to disk.
Doing it this way means that no matter what the original file is named, it always is unique to the user. Even if the user wishes to upload 100 files with the same name, all are unique.
First (and probably obviously), put the users' files in some dedicated place so they don't risk overwriting other stuff.
Second, if you expect lots of files then you may want to have subfolders. The easiest way to do that is to use the first letter of their filename as the folder.
So if I were to upload "smile.jpg", you could store it there: s/smile.jpg
If you're super popular and still have too many files, you can use more letters. And if you expect to have tons of users and you have tons of servers, you can imagine splitting the work by saving on s.example.com/upload/s/smile.jpg (but really if you have tons of servers then you probably already have a transparent way of sharing storage and load).
I've got lots of source code files written in various languages, but none of them have a standard comment at the top (sometimes even across the same project). Some of them don't have any header comment at all :-)
I've been thinking about creating a standard template that I can use at the top of my source files, and was wondering what fields I should include.
I know I want to include my name and a short description of what the file contains/does. Should I also include the date created? The date last modified? The programmer who last modified the file? What other fields have you found to be useful?
Any tips and comments welcome.
Thanks,
Cameron
This seems to be a dying practice.
Some people here on StackOverflow are against code comments altogether (reasoning that code should be written to be self explanatory) While I wouldn't go that far, some of the points of the anti-comment crowd make sense, such as the fact that comments tend to be out of date.
Header blocks of comments suffer from these symptoms even more so. Every organization I've been with that has had these header blocks, they are out of date. They have a author name of some guy who doesnt even work there any more, a description that does not match the code at all (assuming it ever did) and a last modified date, that once compared with version control history, seems to have missed its last dozen updates.
In my personal opinion, keep comments close to the code. If you want to know purpose of, and/or history of, a code file, use your version control system.
Date created, date modified and author who last changed the file should be stored in your source control software.
I usually put:
The main purpose of the file and things within the file.
The project/module the file belongs to.
The license associated with the file (and a LICENSE file in the project root).
Who is responsible for the file (either the team, person, or both)
Back in 2002, when I was straight out of college and jobs were few and far between after the dot-com bust, I joined a service company which used to create software customized for their clients in Java. I had to sit in the office of a client (which was a ramshackle room in an electric sub-station rigged with an AC to keep the servers running), sharing chairs/PCs with other guys in the team. The other engineers (if I can call them engineers ;) in the group used to make changes ad-hoc to the source code, compile the files and put them into production.
No way to figure out who made what change.
No way to figure out why any change was made.
No way to go to previous version of code, unless the engineer "remembered" what he modified.
Backup: Copy over files from the production server, which were replaced with new files.
Location of backup: Home directory of engineer copying over files to production server.
Reports of production servers going down due to botched attempts of copying over files to the server (missed a file to be copied over, backups getting lost or wrong files being copied over or not all files being copied over) were met with shrugs (oh no, is it down? let's see what happened; hey who changed what recently...? ummm...).
During those days, after spending several frustrating days trying to figure out the whos and whys behind the code, I had devised a system for comments in a list in the header of the source file which detailed the following:
Date of change made
Who made the change
Why was the change made
Two months later when the list threatened to challenge the size of the source code in the file, the manager had the bright idea of getting a source version control system.
I have never needed to put any comments in headers of source files (except for copyright notices) in any company I worked since. In my current company, everything else is mostly self-evident by looking at the code, or going to the bug reporting system which is integrated with the source version control system.
What fields do you need? If you have to ask whether to put some info there, you don't really need that info. Unless you are forced, by some bureaucratic incompetence of your employer, I don't see why you should go looking for more info than you already feel should be there.\
In most organizations, all source files have to begin with a legal blurb. If you're really lucky, it's just a one-liner, but in most cases it's a really long block of legalese. As a result, few people ever read these. Our eye just travels to the first program element and then goes up to its documentation.
So if you want to write anything, write it in association with the topmost program element, not the file.
Any other bookkeeping information should generally be part of your version control, not maintained (poorly) in the file itself.
In addition to the comment above stating license, the project that it belongs to, etc I also tend to put the "weird" requirements at the top as well (such as "built with version X of library Y") so you, or the person who picks it up after you won't change something that the program relies on without realizing it (or, if they do, they will at least know what to change back)
A lot depends on whether you're using an auto-documentation generation tool or not.
While I agree with many of the comments, if you're using JavaDoc or some other documentation generating tool that depends on comments, you'll obviously need to include the things it wants to see.
You did not mention that you are using a version control system and your comment in Neil N's answer confirms this for your older code. While using version control is the best way to go I also have experienced many situations where the cost of doing so for older code would not be paid for by the project's sponsor. If you do not have a centralized change history for the project then the change history can be put in the modules. It is good that you are using a version control system for your new code.
Your company name
All rights reserved (c) year - or reference to appropriate license
Project or library this file is for
Module it belongs to
Description of what it contains
History
-------
01/08/2010 - Programmer - version
Initial creation.
01/09/2010 - Programmer - version
Change description.
01/10/2010 - Programmer - version
Change description.
Those useful fields that you mentioned are good ones. Who modified the file and when.
Your version control software should allow for the embedding of keywords within comments. For example, in CVS, the $Id$ will resolve to the file, date/time modified, and user that modified the file. It will automatically be kept up to date with each check-in.
Include the following information:
What this file is for. That's a very useful piece of knowledge and it's more important than anything else. You should tell the reader, why there is such a file, why did you group functions in a separate file/package/module and why they are used. Maybe briefly, one or two lines, but that should be there.
Legal stuff, if appplicant.
Leave the place for special commands of console editors, such as of Emacs.
Add special commands that your auto-documenting system requires.
Things things you shouldn not include are
Who created the file
When it was created
Who modified it the last time
When it was last modified
What was added by the latest modification
You can--and should--retrieve it via the version control system, where it's constantly and automatically kept up-to-date. Let alone that most of these points are just useless.
Who created the file
When it was created
Who modified it the last time
When it was last modified
What was added by the latest modification
Most dependency injection frameworks support initializing the components being injected with various parameters, typically read from an XML configuration file.
This seems like a very convenient place to store settings (like a server name, or a file path that the component will need). But is that the right way to go, or would it make more sense to have a seperate configuration file for settings ? And does it matter, in your opinion, whether the user should be able to change the settings via UI ?
IMHO, it's a matter of common sense. Usually, I keep everything in the same config file, but in different sections. If you use too many config files, it will be harder for someone new in the team to understand your code, for example. But if the file is getting too big, I think it's ok separating them.
About the UI settings, I think developers should make most of the choices, but open some space for configuration. I don't have the link right now, but there's an interesting story of a store which used to sell jam. They would let the customers taste the jams with toast, which highly increased sales (for customers would know the quality of what they were buying). In the beggining, they didn't have many jam options (just 3), and it was a success. When there were too many options (like 20), they noticed customers got a little confused with so many options.
Another reason for reducing configurability is to reduce development time. If you read the book Getting real (I recommend this one), they say a lot of time to build less. In chapter 10, they say:
* Less software is easier to manage.
* Less software reduces your codebase and that means
* Less maintenance busywork (and a happier staff).
* Less software lowers your cost of change so you can adapt quickly. You can change your mind without having to change boatloads of code. Less software results in fewer bugs.
* Less software means less support.
So, IMHO try to find out which settings users would like to change most, and make these configurable. Also, if your system is already at production, and keeps growing slowly, I think you could open more space for configuration as time goes by. Gmail, for example, didn't have many configuration options, but as users got used to the tool, they started creating options for the users, like changing themes and other features of google labs. This way, the learning curve "doesn't hurt" users :).
Hope I helped.
I would probably store the settings in a separate file, to make it more clear what settings might need modification in different environments. This also makes it easier for people not familiar with your dependency injection framework (e.g., system administrators, end users) to modify the settings.
If this is a very small application, and the settings will only be changed by developers, I might keep the settings in the DI configuration.