Skip to content

Make current user available in Custom Scripts #3705

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
2bithacker opened this issue Nov 21, 2019 · 2 comments · Fixed by #3775
Closed

Make current user available in Custom Scripts #3705

2bithacker opened this issue Nov 21, 2019 · 2 comments · Fixed by #3775
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application

Comments

@2bithacker
Copy link

Environment

  • Python version: 3.6.8
  • NetBox version: 2.6.7

Proposed Functionality

Make the currently logged in user available to Custom Scripts. It may be beneficial to make the entire request context available, but all I need currently is the user.

Use Case

In my use case, we have a policy of commenting on Prefixes with the user who allocated and assigned the prefix to a site. I'm attempting to automate this process using a Custom Script, but currently need to ask the user for their username, despite them being logged in.

Database Changes

None

External Dependencies

None

@jeremystretch jeremystretch added status: under review Further discussion is needed to determine this issue's scope and/or implementation type: feature Introduction of new functionality to the application labels Nov 21, 2019
@hellerve
Copy link
Contributor

I’m not personally using that kind of context, so I can’t say much, but I do think that spending a minute to think about what properties of the request context might make sense to be shared might be worthwhile.

I don’t think that sharing the whole request is necessarily a good idea. While I think custom scripts are inherently trusted, there is just no need to expose the session, for instance. This might seem ridiculous (because the script already has access to Python and its capabilities anyway), but I think that it actually makes sense to not expose those bits of “sensitive” information anyway.

@jeremystretch jeremystretch added status: accepted This issue has been accepted for implementation and removed status: under review Further discussion is needed to determine this issue's scope and/or implementation labels Dec 6, 2019
@jeremystretch
Copy link
Member

@hellerve While I appreciate the security consciousness, I don't think there's anything in the request context that could be considered more privileged than the access already given to a script (which is essentially everything). Given that a custom script can already do things like create users and reset passwords, providing access to the session ID and other request parameters isn't much of a concern.

jeremystretch added a commit that referenced this issue Dec 26, 2019
@lock lock bot locked as resolved and limited conversation to collaborators Mar 27, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
status: accepted This issue has been accepted for implementation type: feature Introduction of new functionality to the application
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants