I'm running 2 notebook server. The first is private, and need an authentication in order to edit the notebooks. The other one is public, and I would like to put it as a "Show room".
In fact, the public one is likely an equivalent of Apache's "index of", showing the differents notebooks I made. I would like to know if there's a way to disable the execution of cells in all the notebooks on the public server.
Related
We teach a Deep Learning course on our supercomputers, and one step which is prone for improvement/automation is the connection to the machines and text editing.
Our users come with extremely distinct backgrounds: from people who set up their own linux clusters to people who barely understand the concept of a text editor, given they always edited files on jupyter or collab.
What I would like to do is a double-click package users can download and it configures VS code to connect to our machines, downloads dependencies (like the extension for ssh), generate new ssh keys, and gives support for viewing image files, csv and so on.
My impression is that the way of doing so is, instead of a full package containing vs code and our configurations, would be to make an extension of VS code itself which does that, but I have no idea where to begin or if such a thing even makes sense.
Any pointers are welcome.
In VS Code 1.57, I see this on the left of my status bar:
What is Restricted mode and how I can I remove this from my status bar?
How to disable the "Trust" feature
This will disable all prompts and trust mode features, making vscode behave exactly like it did before this feature was added.
GUI (ctrl ,)
Search for "Trust" in the settings menu and uncheck: security.workspace.trust.enabled
settings.json
add the following line: "security.workspace.trust.enabled": false
What is Restricted Mode?
At first glance, this new "Restricted Mode" seems unnecessary and obtrusive.
I believe its purpose is to prevent execution of untrusted code - e.g. as a result of an extension or using the "debug" option on an untrusted file. It seems to work in a similar manner to the restricted mode on MS Office apps, like MS Word, which restricts editing, saving and printing files until manually enabled.
From the Visual Studio Code documentation on Workspace Trust:
Restricted Mode tries to prevent automatic code execution by disabling or limiting the operation of several VS Code features: tasks, debugging, workspace settings, and extensions.
Personally, I have never come up against a situation where this would have been a problem and it seems like a constant nuisance for the sake of the one occasion it could be useful. That said, I imagine some people work with potentially dodgy files more often.
What can I do about it?
There are four new settings that allow us to customise this feature:
If you wanted to remove the feature, you can just switch off Trust, which "Controls whether or not workspace trust is enabled within VS Code". I have tried this and it does seem to completely disable this new feature - even removing related options from the command palette.
You can also control how VS Code works when opening an empty environment and how VS Code behaves with regards to untrusted files.
If you keep "Trust" enabled, you can also configure folders that you consider "safe" - for example your usual workspace, vs. your downloads folder.
Follow these steps to configure your trusted folders:
Hit CTRL+SHIFT+P (or your local equivalent) to open the Command Palette.
Start typing Workspaces: Manage Workspace Trust and select the entry when it comes up.
Alternatively, click the cog and select "Manage Workplace Trust", as it seems there is a new entry for it there.
You will be presented with the following form, showing the option to trust/untrust the current window and an option at the bottom-left to configure trusted folders:
Select the "Add Folder" button at the bottom and add folders that you trust.
Where can I find more information?
The release notes for VS Code v1.57 can be found on GitHub. There is also a specific page dedicated to workspace trust on code.visualstudio.com.
Another new option, from VSCode 1.58 (June 2021)
Workspace Trust Banner Setting
Speaking of settings to configure the Workspace Trust feature, you'll notice a new setting to configure when the banner appears to notify indicate the current window is in restricted mode.
Like the security.workspace.trust.startupPrompt setting, the new security.workspace.trust.banner allows you to completely disable the banner after you've become familiar with the Workspace Trust feature and don't need any indication of which of your windows are in restricted mode.
By default, this banner shows once per workspace and remains until it is dismmissed.
Note: the new (July 2021) article "Workspace Trust" by Chris Dias details that "Trust" concept.
We specifically ask if you trust the authors of this workspace because VS Code can't tell if the code is malicious or not (hey, we just know 1's and 0's), where it came from, if you intend to contribute to the project, etc.
You, on the other hand, are smart and you know where the code came from: you (ok), your company (probably ok), your buddy Kai (depends), or some random person on the internet (definitely not).
That knowledge helps make the tool smarter. If you trust the author, great! The tools and extensions have the green light to do their thing and provide a magical experience, and we're not going to bug you again.
If you don't, you are telling us be careful VS Code, don't execute any code. This is what we call Restricted Mode, where potentially harmful functionality is disabled so you can more safely browse the code and eventually make an informed decision.
Note:
From our own dogfooding as well as through interviews with other developers, we found that people generally have a primary folder where they put all their sources and consider it trustworthy.
We therefore added the ability to trust the parent folder directly from the dialog.
You can trust it and all the sub folders with one click and then you won't see the trust prompt again.
Restricted Mode
When prompted by the Workspace Trust dialog, if you choose No, I don't trust the authors, VS Code will go into Restricted Mode to prevent code execution. The workbench will display a banner at the top with links to Manage your folder via the Workspace Trust editor and Learn More about Workspace Trust.
You will also see a Restricted Mode badge in the Status bar.
Restricted Mode tries to prevent automatic code execution by disabling or limiting the operation of several VS Code features tasks, debugging, workspace settings, and extensions.
To see the full list of features disabled in Restricted Mode, you can open the Workspace Trust editor via the Manage link in the banner, or by clicking the Restricted Mode badge in the Status bar.
More Information
Restricted mode means that you are currently working in an untrusted workspace ('restricted mode'). In 'restricted mode', some editor features (debugging, tasks, some extensions) are disabled to keep you safe when dealing with a project from an unknown source.
To disable the Restricted mode status bar entry:
Right click in the status bar
Uncheck the workspace trust entry
Note that this only hides the status bar entry, it does not change the trusted state of the workspace. This answer covers more details on workspace trust, how to trust a workspace (which also removes the status bar entry), and how to disable workspace trust entirely if needed
Even after disabling the Restricted Mode status bar entry, you can always trust the workspace with the Workspace: Manage Workspace Trust command
I have a test case reporting scheme delivered in HTML that is complex in its own right and not easily ported to a VSCode extension. I would like to launch a Debug Configuration for each failing test case from the browser displaying the report. I have already been able to modify the report and have added a copy/paste widget for each test case's associated command. However I would like to do something to the effect of:
Launch a service as a VSCode extension that can handle requests
Formulate those requests in a way that can dynamically create launch configurations
It may be that I am stuck writing a Debug Adapter without the bells and whistles of interacting with the report.
That being said, if this is a solved problem or has a framework for solving with VSCode (and I realize remote execution could be a Very Bad Thing for VSCode to allow), I have not been able to find it through an existing extension.
I welcome your ideas.
This is perhaps not as open ended as it sounds...my question ultimately is: can VSCode operate as a service to be requested by web interfaces? Even if it could be done via Localhost this would be a boon. If it can be done over ssh with authentication, that would also be a bonus.
One way of getting VSCode to handle requests would be by invoking a vscode:// URI. This requires your extension to implement a URI handler. After the mandatory parts of the URI, you could have arbitrary data with whatever information you need.
Something that might or might not be an issue for your use case is that invoking such a URI triggers a popup in VSCode / doesn't work silently:
For dynamically creating launch configurations, you can use the vscode.debug.startDebugging() API.
Okay, this is kind of odd and it is driving us nuts. I'll outline what is going on as best I can, then I can provide specific details and/or code as folks request it, because I'm not sure what will be needed to suss this out.
I have an access database I have built so our analysts can work within a queue, select records, do whatever research is needed, then either mark the record in question as okay, or fill in some blanks and mark it as needing a dispute (we work in billing).
Basically, the database opens and a hidden form pulls the NT User Name from the local machine, then opens a visible form that queries the database via SQL ODBC to display a list of records with that NT User Name attached to them.
The user can then scroll through the records, select them to get more information, and click a button to mark them as okay, or another to mark them as needing a dispute.
If they click the okay button, it fires off an update query to mark the record as okay. If they click the dispute button, then it opens a third form to show them the line item they are disputing with values from all of the other text fields on the form that they can select from/fill in. On that form there is a button to commit the dispute, which fires off another query to update the values into the same table as the 'okay' button.
So, the issue is, that this all works perfectly on my workhorse machine, and an essentially naked test machine. It also works on another co-worker's machine. However, whenever we try to run it on two other coworkers' machines, everything works just fine, except for any of the queries that attempt to write back to the ODBC connection. All of the read-only stuff works just fine, just not the updates. But the updates work perfectly, and super-fast on my machine, my test rig, and my other co-worker's machine.
We've tried reinstalling the ODBC connection, and the ODBC SQL Drivers.
No go.
We've tried just opening the table in question on the affected machines and making direct edits to the table.
This works if no forms are open in the database, but as soon as we open a form, no update query will run against the table.
So, we tried commenting out all code on all open forms except the docmd.openquery code for the single button we used to test the update query.
No go.
We even built a new form with just a button on it that triggers a new update query that makes only one simple update (Now()) to the table in question.
This runs fine on its own, but times out when run off the button click from the form.
We tried changing the MS Office install on one machine to 'run all from computer' to make sure all necessary components are installed/present.
No go.
We tried installing the ODBC connection both via the normal windows interface, and through the access linked table manager interface.
No go.
We tried installing both 64-bit and 32-bit ODBC connections, both under USER DSN and SYSTEM DSN, and all permutations of one and not the other that we could think of.
No go.
It seems that no update query will write to that table while any form is open, but works just fine with no forms open. But only on these other two machines. Everything works fine on the other three machines we've tested on, whether forms are open or not.
We're kind of at wit's end here and don't know where to go. Google is proving unhelpful, possibly because we just don't know exactly how to search the problem out.
Here's basic technical stuff and I am happy to provide whatever other details, code, queries, etc. that are needed to troubleshoot upon request:
OS: Windows 7 Enterprise 64-bit
Software: MS Office Enterprise 2013 32-bit
ODBC: SQL Server
All users have admin access to their respective machines.
Turns out that the issue here seems to have been an intermittent issue with Access being unable to determine which record to update due to the way we were calling details from a continuous form.
We went back to formula on our UI and built it so there is only ever one record on a form when we try to make changes to records, so there can be no system confusion about what record to update.
Still no clue as to why it was working intermittently, but the new iteration is working now.
Thank you all for your questions and suggestions. :)
In my *.mdb file I have a macro with an action that runs TransferText and gives me an Error Number of 2950 which according to Microsoft means that the document is not trusted, as far as I know it is trusted! It's located in the Trust Center Trusted Locations.
Is there an explanation point next to the Action causing this in the macro whose tooltip reads This action will not be allowed if the database is not Trusted.
I already tried running a compact and repair on it, what could be causing this?
Method 1: Enable the database for the current session
When you use this method, Access 2007 enables the database until you close the database. To enable the database for the current session, follow these steps:
On the Message Bar, click Options.
In the Microsoft Office Security Options dialog box, click Enable this content, and then click OK.
Note You must repeat these steps every time that you open the database.
Check here: https://support.microsoft.com/en-us/kb/931407
The problem can be as simple as not having first established an ODBC connection. I was getting this macro error (2950), and I ended up reading all the support threads, getting nowhere.
Then it struck me to install our ERP client first --which is the front-end for the database I was trying to access ...with Access.
Doing this established an ODBC configuration, so now when I opened my Access file, an ODBC prompt opened up before I even got to any of the functions that were triggering the error. In hindsight, I could have passed on installing the ERP client, and just went to the ODBC settings in Windows, and pointed a connection to the SQL table.
In my case there was a naming conflict. The macro in turn called a VBA function, and I had inadvertently named the function with the same name as the module it was in. They were both named "RobertsReport". Once I changed the name, everything worked as expected.
Tip: As troubleshooting steps, try running the macro solo by double-clicking on it. If you can, copy only the line that generates the error to a new macro to test it by itself, and of course include any preceding commands it may need to run properly. Once I did this it greatly narrowed down the problem until the lightbulb came on over my head.