In our group we had plain text passwords on our TRAC wiki pages. Now we are granting external users access to those wiki pages. Of course we removed the passwords from the page.
BUT: In the page history you can still see the passwords.
My question is: Is there a way to restrict the user rights to only see the current version of the page and not the page's history?
Not with Trac core alone.
To be exact, likely you cannot see the passwords in the history (commented version lineup), but in the wiki page view of previous versions. This is where the issue starts to get complicated. Technically it is the same page view template, just with older content retrieved from the stack of wiki content by page name and version.
What you want is to just allow latest version views, but lock older ones. You write a mini-plugin to filter all version requests and redirect for user sessions without appropriate permission, say you define an extra permission WIKI_VIEW_REV and allow to inherit it by WIKI_ADMIN (and of course implicitly TRAC_ADMIN too).
Related
I have created a simple (display only) SPFx webpart that makes calls into a list on the same site as it is used. Standard users have read access over this list, site owners have Full Control. When I add the part to a page, even site owners cannot see it. Site Members (& Owners) are able to see the page (published or not), but the content which should be displayed by the webpart is missing. Note that the basic html is visible, but the data which should be retrieved is not. If I elevate a site owner to a site admin permission level, the webpart then works as intended and data is retrieved correctly and displayed. Note also that other webparts on other pages served from the same library work correctly for all groups.
Does anyone have any suggestions to explain this behaviour?
I have tried: Rebuilding and publishing webparts, new test pages created by the same and other user accounts both published and unpublished. I've carefully changed permissions on the "Site pages" library, the "ClientSideAssets" library and the site scoped app library itself.
I've answered my own question here. The error was caused by a REST query into the SPO list that contained a taxonomy (managed metadata) field. Expanding this field appeared to require the highest permission levels, thus all non admin users were unable to retrieve the data.
I later found an excellent article detailing the subject here.
I was able to trace this by serving through gulp into the online workbench, copying that URL into an incognito window for a different user account, and utilising the (Chrome) debugging tools. This tidy solution might potentially be of use to someone.
I'm setting up a wiki at the moment and I want it to be completely private and only be accessible for a specific user group.
My first step was:
$wgGroupPermissions['*']['read'] = false;
that way no one (but admins I guess) should be able to read any content of the Wiki.
After that I created some groups to allow read only, read edit and creating allowance etc.
Sadly I tried to register a new test account and I could still read the main wiki page even though I changed the permission that no one should be able to read it except the user groups I created.
Do I miss something?
You need to add $wgGroupPermissions['user']['read'] = false; as * still allows visitors in the users group to read.
That method specifically allows Users that have created accounts to view the wiki. See this manual page: https://www.mediawiki.org/wiki/Manual:Preventing_access#Restrict_viewing_of_all_pages, it's the second Warning. So you may want to also restrict account creation.
Whenever we deploy our sharepoint website we have pages that show a login-window to anonymous users (and after that a 401 if the user does not login). This login-window disappears once we login from any machine. After that: The anonymous users can watch that site, too.
The Page is in a published state and has a major version.
This is no big problem for us as we can solve it like described above. I just wonder what causes this weird behaviour. Any idea?
Solved!
It really was a strange reason. (Easy once I found out). This time it is surprisingly no sharepoint-error.
The problem was the following: We use a webpart that generated thumbnails in the correct size so our users can assign pictures of any size. These thumbnails are then saved in the cache. Now our users added the sharepoint-thumbnail of those pictures which lie in a protected area.
Now when logged in the protected images are collected and saved in the Cache which can be accessed by anyone.
Simple reason - complex error behaviour :)
I've been asked to create a solution where people log in and are able to upload and download off of our work server. So John uploads a photo, and Jen can download it, for example. They also have to authenticate themselves.
Can someone give me a rough overview of how to implement this? I'm familiar enough with MySQL, C#, and JavaScript.
The rough overview
This should just be a matter of planning out the pieces.
at the very top of the page, put some code that checks if a user is logged in. If not, show a login form (or redirect to...). If they are logged in, show the rest of the page. If not, you'll need some logic to show a form, and then check it once it's submitted for authentication, and set a SESSION cookie or something similar.
Once the user is logged in, on the homepage, you might have an file-upload form and a listing of existing files. How you would style would depend on how many files you might expect to have. To keep things extremely simple, you could simple iterate through whatever files are in the upload directory. If you expect many more files than that, you may consider using a db.
Handle a file upload by sanitizing filenames (checking for filetype/filesize if you want to limit those) and putting the file into the directory.
Force the users to download the files (instead of having the browser decide what to do with them) for security purposes. Implementing this on certain filetypes may also be acceptable.
Other thoughts
You probably would not want the users to be able to excecute any files, so keeping the file directory hidden would be a good idea.
Keeping track of who uploaded and downloaded what is also doable, but would add another layer of complication to the script.
Some e-Marketing tools claim to choose which web page to display based on where you were before. That is, if you've been browsing truck sites and then go to Ford.com, your first page would be of the Ford Explorer.
I know you can get the immediate preceding page with HTTP_REFERRER, but how do you know where they were 6 sites ago?
Javascript this should get you started: http://www.dicabrio.com/javascript/steal-history.php
There are more nefarius means to: http://ha.ckers.org/blog/20070228/steal-browser-history-without-javascript/
Edit:I wanted to add that although this works it is a sleazy marketing teqnique and an invasion of privacy.
Unrelated but relevant, if you only want to look one page back and you can't get to the headers of a page, then document.referrer gives you the place a visitor came from.
You can't access the values for the entries in browser history (neither client side nor server side). All you can do is to send the browser back or forward a number of steps. The entries of the history are otherwise hidden from programmatic access.
Also note that HTTP_REFERER won't be there if the user typed the address in the URL bar instead of following a link to your page.
The browser history can't be directly accessed, but you can compare a list of sites with the user's history. This can be done because the browser attributes a different CSS style to a link that hasn't been visited and one that has.
Using this style difference you can change the content of you pages using pure CSS, but in general javascript is used. There is a good article here about using this trick to improve the user experience by displaying only the RSS aggregator or social bookmarking links that the user actually uses: http://www.niallkennedy.com/blog/2008/02/browser-history-sniff.html