I'm working on a project, and I want to authenticate into, and use the Github API, in order to make some modifications to the project. Simple operations such as creating a new branch in the existing repo, creating a pull request etc., are some of the actions I am planning to do.
For the authentication to happen, I understand we can use a username/password combo, or create a personal access token(which is best practice). For now, I want to test it using username and password. I am looking for ways to do that, and some solutions suggested using GithubClient library.
For using this library, I am trying to understand..what is the dependency/dependencies I need to include for this? And how can I use GithubClient for this? I am struggling to find online resources for this, so reaching out here for any answers/documentation on this process.
Related
Moodle is a platform for creating training and educational material. By default, it is possible to make the content by clicking on controls.
GitHub is a place for version management and teamwork.
Question: I wondered if there is a way to (programmatically) populate/update a Moodle training from a GitHub repository. Does Moodle offer an API that would allow the implementation of such a functionality?
Idea:
The GitHub repository contains mark-down files in a specific format and folder structure.
Yes. Theoretically. Moodle offers an API (https://docs.moodle.org/dev/Web_service_API_functions) through which you can update courses along with much other functionality.
You would have to write the script yourself, of course. I've been briefly looking in to this as well, but the moodle webservice API is not intuitive and is underdocumented. There's been talk of making a more sensible, RESTful API (https://tracker.moodle.org/browse/MDL-49607) but it doesn't seem to have gotten anywhere.
I couldn't find information on how other people solve this, so maybe you can help me out.
What I have
Multiple Services with REST APIs, that are secured using OpenID Connect. Connections between the Services work fine.
Now I have multiple developers, who sometimes need to write and execute local scripts (Python, R, Bash etc.) for quick analysis and testing.
What I want
I want to enable the developers to use the services as easy as possible, but still respecting security concerns.
What I tried
I defined the script itself as a client. Therefore I created a public client in my OIDC product, which is called somewhat like 'developer-scripts'. Using a library which handles the oauth dance, I can then execute the script connecting as aforesaid client. First time, the browser pops up and requests the user to authenticate and therefore authorize the client to use the REST API on behalf of the user. After that, the tokens are cached and I can easily continue working on that script.
This simplified drawing tries to summarize, what I just described
That works perfectly fine and regarding security I'm glad that credentials are not saved on the local computers as it was before with e.g. Basic Authentication. Furthermore, I'm able to control the access to different services on a user level.
Other ideas, which didn't convince me:
every web service also has an public client which can then be used as a client by the scripts (so the scripts aren't defined as clients anymore)
token generation is done somewhere else and the developer just adds the generated access/refresh token to the script
My problem
What concerns me about my current solution is the definition of that client. In the described case it would be either a generic client used by all developers for all scripts, or a new client for every developer who want's to write a local script. The latter seems to be a lot of overhead, the former may be a security problem?
So finally I'm asking the question: Are there any known best practices for my described use case?
EDIT:
I found a small article by [Martin Fowler](https://martinfowler.com/articles/command-line-google.html), he is basically explaining, how he is receiving a token to use for a local script. But in his case, he's using it for one certain use case, and not as a general public client. So unfortunately it doesn't really contribute to my answer.
I've been trying to implement a way to download all the changes made by a particular user in salesforce using PowerShell script & create a package The changes could be anything whether it can be added or modified, Apex classes, profiles, Account, etc based on the modified by the user, component ID, timestamp, etc. below is the URL that exposes the API. The URL Does not explain any way to do this by using a script.
https://developer.salesforce.com/docs/atlas.en-us.api_meta.meta/api_meta/meta_listmetadata.htm
Does anyone know how I can implement this?
Regards,
Kramer
Salesforce orgs other than scratch orgs do not currently provide source tracking, which makes it possible to pinpoint user changes in metadata and extract only those changes. This is done by an SFDX/Metadata API client, like Salesforce DX or CumulusCI (disclaimer: I'm on the CumulusCI team).
I would not try to implement a Metadata API client in PowerShell; instead, harness one of the existing tools to do so.
Salesforce orgs other than scratch orgs don't provide source tracking at present. To identify user changes, you can either
Attempt to extract all metadata and diff it against your version control, which is considerably harder than it sounds and is implemented by a variety of commercial DevOps tools for Salesforce (GearSet, Copado, etc).
Have the user manually add components to a Change Set or Unmanaged Package, and use a Metadata API client as above to retrieve the contents of that package. (Little-known fact, a Change Set can be retrieved as a package!)
To emphasize: DevOps on Salesforce does not work like other platforms. Working on the Metadata API requires a fair amount of time investment and specialization. Harness the existing work of the Salesforce community where you can, but be aware that the task you are laying out may be rather more involved than you think and it's not necessarily something you can just throw together from off-the-shelf components.
I am using github to share a set of SPARQL queries:
http://www.boisvert.me.uk/opendata/sparql_aq+.html?file=specific%20sensor.txt
Currently the simple work allows end-users to access queries stored on the github repository, but ultimately I want to allow them to also modify the queries, as with a pastebin, and make use of the repository to better manage the shared system. Ideally I would want end-users who may not be very tech-savvy, to be able to make minor changes to queries to an open, linked data endpoint: so to keep the technology barrier low.
My problem is this: how best to structure the github project and exploit the API to make the most of the available information? I can think of different points:
Currently the project (https://github.com/boisvert/unshaql) holds client code and example queries. Does it make a difference to create an independent project (separate from the web client code) for SPARQL queries?
I would use directories within the project to classify/tag queries, and file names to title them. Are there better alternatives? It strikes me that a hierarchical structure is not a good fit to tags.
When end-users save, a simpler (and cruder) option is to allow them to push their file into just one branch, which holds the examples. A better engineered one would be to allow them to use their github credentials to fork the set of SPARQL queries and edit theirs, but with unaware users, how do I avoid creating a mess?
I think that a rigular Github repository is a rather bad fit for this kind of content. If your users have a GitHub account, you should probably use Gists instead: https://help.github.com/articles/about-gists/ I never used this myself, but it seems perfectly adapted to what you are planning. Your site could become a DB of tags over user-provided gists. That would however lock you into GitHub-specific solutions.
Even if you go for a regular repository, you should not allow the users to commit into the repository hosting your code: that would be a serious security hazard as you won't be able to control the parts of the repository to which they are allowed to commit.
If you setup two repositories, it's rather easy to have the code of a webpage in a repository, and the code automatically commited in another repository (under an anonymous identity so that your users don't have to create a github account).
Also, note that the oauth token should never be stored in a public repository (or the GitHub robots will invalidate it in a matter of hours).
See Hiding GitHub token in .gitconfig for a solution to this sub-problem.
We are currently using Freshdesk for our customer support and GitHub for our code. On receiving a bug or an improvement feature request via Freshdesk, we would like to forward that ticket (with all the details + screenshots) to an email in GitHub so an issue is created automatically on GitHub. That would save us a manual entry.
Look forward to an advice on this or a better solution.
NOTE: Had come across https://zapier.com/zapbook/gmail/github/72/create-github-issue-email , but we would prefer a direct interaction without a third-party app in between.
Creating an issue to GitHub wouldn't be done by "sending an email", but only by using the GitHub v3 issue API (like this script, for example, to migrate issues to GitHub)
That means in your case having a trigger on FreshDesk (or an "Observer" to call a webhook) which would parse the ticket and create the appropriate bug report on GitHub.
From the Observer/WebHook help page:
Webhooks also come handy when you want to trigger an action in an external application or tool (as well as some updates that the Observer can't perform, like update time entry on a ticket or add a note to a ticket)
You would manage that webhook locally on your side, and that callback would in turn call the right GitHub API commands to create the GitHub issue.
We had similar needs and built a very simple tool to let anyone in the team send/forward emails to create GitHub issues. We were using it internally at first so that non engineering team members didn't have to go to GitHub to create issues. We just made it available to anyone (and free). It supports attachments.
You can find it at https://fire.fundersclub.com.