I want to create an OAuth 2 Server mainly for self education purposes. I do understand the concepts the OAuth framework is based on and I do understand the the authentication process(what is send/received and why).
I'm pretty familiar with java and the Spring framework as such my intentions are to use this technologies.
My question is, In order to implement an OAuth 2 Server:
Do I just follow the rfc6749 to the letter and write my code based on this? Handling everything by my self? from the data and how its stored in the database(if a database is used) to serving the same error/message response?
Do I use a dependency or a library maybe, which will prevent me from reinventing the wheel (as far as OAuth 2 is concerned)?
Or is there and already free service which I can install and does exactly with some minor configurations.
Thanks in regards. :)
If you're writing something new from scratch, I would recommend you would take a look at the upcoming OAuth 2.1 spec. Largely compatible with OAuth2, but there's a few features removed and some stuff added. It might be worth starting off with something that's immediately the bleeding edge.
Yes, probably. Unless you can't find a good one?
Yes, there's open source implementations and free hosted services.
I think what you want is Keycloak.
Thanks.
This question already has an answer here:
How to use both Blazor client and server in same web
(1 answer)
Closed 2 years ago.
I know that there is the same question here somewhere that has been answered and i have heard people from the ndc conferences that say that "there is nothing stopping you from doing that" and there "should be a support for that" but i didn't get the answer to my second question and i haven't managed to get an implementation somewhere about both.
The second part of my question is that can i run both at the same time in a page. This might be useful because i can use the server side to get the data from my database and then use the client side to render the page and other components that do not pose a security risk if they are compiled in the clients browser.
Can somebody help me out, and if you can link me projects that somebody has tested or published that would be very helpful.
PS: I'm sorry if i made grammatical errors, i hope i was clear enough for you guys to understand my questions.
No, currently not.
However this is one feature the Blazor team is considering for the future.
However you can just use a common ASP.NET Core backend in the same solution to get the data from database and a shared project for your models.
Wondering if somebody done it before. We are using WCF in our current architecture and when internally not going over the boundaries I would like the ability to reference the project directly.
I don't want to use tcp or named pipes, I would like to know if is technically possible to alternate between a project reference or normal communication with WCF eg tcp-http etc..
Is there any example or approaches to achieve this?
Looked on google and stackoverflow but I could not find an answer if the title was the same
Many thanks
I would like to start using the WCF Rest Starter Kit's HttpClient to build clients for my Restful WCF services and I was wondering...
If anyone is currently experience
any problems with it
Can I be confident that future versions of
the component (just the HttpClient,
not worried about the rest of the
kit) will not contain significant changes to the API?
It seems like a pretty straight-forward component so I can't imagine any major changes with it, but maybe somebody here who is more "in the know" could give me a heads up.
Thanks in advance.
I work on the WCF team and I wrote most of the HttpClient code.
No major known issues. The public issue tracker is at http://aspnet.codeplex.com/WorkItem/List.aspx (search for HttpClient or WCF REST).
Microsoft does reserve the right to change it. That being said, I don't think there will be significant changes to the API that has shipped. (Maybe some minor renaming.) We're mostly considering adding features/capabilities, which shouldn't break your existing code.
A great way to tell us about your usage is via the forum: http://go.microsoft.com/?linkid=9632199 .
Until it's released, Microsoft will surely reserve the right to change it.
On the other hand, if you make sure they know you're using it, you're somewhat less likely to be, ummmm, inconvenienced by any changes.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I am planning on putting up a web service, or some other service exposed over the internet. I would like to create an API for applications to interact with this service. I would like the API to be usable in different languages, such as Java, C++, C#, or PHP. How can I maintain one code base for my API, but distribute nice packaged binaries for all these languages? Also, I may want to consider this could be cross platform as well.
Update 1
I'm early days on Web Services, but I
think one of the key points is that
lots of tooling supports the
implementation of clients based on the
description of the service like WDSL.
I've not delivered any client-side
software with anything I've done, I
expect any user to be able to build
their own clients suited to their
needs. --Brabster's Answer
I am not opposed to making it a straight web service then giving out a WSDL file. But what if I want the client API to do some logic, encryption, error checking or so on?
Update 2
As far as expecting the client that is
using your API to do anything, you
can't! There is nothing you will be
able to do to ensure that the consumer
of the API will do anything right.
That's why robust error handling is so
important. You must check and double
check any and everything that comes
from the client. You must always be
suspicious of it, and even assume that
it is malicious. There really is no
good way around that fact. --Ryan Guill's Answer
My original idea was to create a DLL or Assembly in .NET, then the client is making calls into this code that is running client side. This code may talk via any communications protocol back to the server, but my API would be running on their box. I guess REST does not really accomplish this. It seems like in REST everything is still an HTTP post. It is almost web services with out soap.
Update 3
I have accepted Ryan Guill's answer. I think the general idea is that I need to expose a network service of some sort, with the lowest barrier to the client. That way anyone can connect. Then just have all my code run on the server. That seems to be accepted as the only want to really achieve the platform and language independence I am after.
Thanks for all the input.
I would use a REST API, similar to the way Flickr's API works: http://flickr.com/services/api/
It is fairly simple to create and maintain, the biggest downsides are that it takes a lot of documentation (but pretty much any way you do an API will have this issue) and that robust error handling is a must.
But in my opinion, it's the best way to create an API that is the closest to cross platform/cross language.
More information here: http://www.xfront.com/REST-Web-Services.html
Update: The submitter added the following to the post:
I am not opposed to making it a straight web service then giving out a WSDL file. But what if I want the client API to do some logic, encryption, error checking or so on?
I personally do not like using SOAP (using a WSDL). There is a lot of inherent overhead to using SOAP, both on the server and the client. I think that is why you see more and more public API's being written using REST. It really lowers the barrier to entry to the lowest common denominator, allowing anything that can use basic HTTP (GET and POST (also PUT and DELETE for the "proper" way of doing it)) to use the API.
Some more examples of public API's written using REST: twitter, vimeo, Google
As far as expecting the client that is using your API to do anything, you can't! There is nothing you will be able to do to ensure that the consumer of the API will do anything right. That's why robust error handling is so important. You must check and double check any and everything that comes from the client. You must always be suspicious of it, and even assume that it is malicious. There really is no good way around that fact.
Update 2: the submitter added the following to the post:
My original idea was to create a DLL or Assembly in .NET, then the client is making calls into this code that is running client side. This code may talk via any communications protocol back to the server, but my API would be running on their box. I guess REST does not really accomplish this. It seems like in REST everything is still an HTTP post. It is almost web services with out soap.
You can certainly do this, but that is only going to work for .NET languages, meaning that your cross-platform and cross-language benefits are out the window. And still, in the end, are you really preventing anything? The developer is going to either use your remote API, or your local DLL or Assembly. Either way, he is going to have to know how to use it and use it right, otherwise you are going to throw an error. All you are really doing is changing where the errors get thrown from. Which may be important to you (if so, mention why) but really isn't changing anything in the equation.
But you are somewhat correct in saying REST is kind of like web-services without the SOAP. Technically REST is web-services too, its just that web-services have come to generally mean SOAP. It really is a different way of achieving the same thing. The biggest differences are though that it takes more programming and thought on your side (and potentially more programming on the client side) but you trade that for robustness, less overhead in both the consumer and the server, and the widest possible audience for the API. It really is the lowest common denominator.
I'm early days on Web Services, but I think one of the key points is that lots of tooling supports the implementation of clients based on the description of the service like WDSL.
I've not delivered any client-side software with anything I've done, I expect any user to be able to build their own clients suited to their needs.
If you check out the flickr API as suggested by one of your other answers, I don't think they supply client side code, other people have built and contributed client side stuff.
I suggest writing the API in the Haxe programming language so that the source code can be directly translated to all the programming languages you mentioned. The Haxe programming language can be translated (or "trans-compiled") to all of the programming languages that you mentioned in the original post, as well as a few others.
Simple answer, no.
Complex answer: create an API and compile it to a COM dll. Then, just build the wrapper code for the languages that can't handle that.
Simple answer #2, make the original service so trivial, or so universally acceptable, as to not require an API (I usually implemented this through server-side database polling. Ugly but any language that can access a database can utilize the program).