I'm new in SSL concept , Sorry I don't know my question is correct or not ...
Recently I wanna know root_certificates.hpp should be specific for every clients? I mean that clients should create it by openssl?? or it's general and all clients can use it?
root_certificates.hpp is only there to make the examples portable.
On your system, you typically can use set_default_verify_paths.
If your application additional requirements, which is often, you will want to include your own certificate store in the way that your application chooses. There are more details to customize the verification process: https://www.boost.org/doc/libs/1_80_0/doc/html/boost_asio/reference/ssl__context.html (see also https://www.boost.org/doc/libs/1_80_0/doc/html/boost_asio/reference/ssl__stream/set_verify_callback.html).
Related
With ga.js I could track offline activity and send to my custom server or store in localhist by overriding the sendHitTask.
Like this:
https://www.google.se/amp/s/www.simoahava.com/amp/analytics/track-users-who-are-offline-in-google-analytics/
How can I achieve the same with gtag.js so I can customize where and in what data structure to send hits?
I know it's been a while since you've asked this question, but I wanted to share my findings regarding this matter:
Although gtag.js doesn't support sendHitTask (or an equivalent, as far as I know) it does support the transport_url parameter.
With this parameter you can set an alternate Transport URL to send the data to. It's originally designed to work with Server Side Tracking but it can also be used to capture requests to /g/collect/ or /r/collect/ endpoints on your own server.
I know it only partially resolves your issue, because you can't fully decide where to send the data. But at least it allows to alter the server where the data is sent.
Hope it helps!
I wonder if someone might be able to help us or offer some advice. We are a Java focused team, and are looking at extending our in house Authentication service, to offload most of the authentication , to use an LDAP server. That way we can simply use an out of the box password policy, which meets our criteria, plus we can use stuff such as replication etc. We are investigating which is the best free LDAP server to use.
So far we have investigated :
OpenLDAP (We found this is written in C, and documentation is not all that great).
Apache DS (We found this is good, but has a basic password policy. Mainly it does not seem to be extendable to fit one of our requirements (that the password policy should enforce mixed case characters, etc etc). This is surprising as the basic config options are ofcourse supported, eg. minimum length of password, maximum retries before being locked out etc etc.
Sun OpenDS (This fits all our needs, but no longer seems to be supported??. Please advise us if this assumption is wrong?It has great support for Password Validators, so that we can handle enforcement of mixed case passwords etc etc).
Oracle Unified Directory - This is the SUN DS server which is supprted. However, Oracle Unified Directory is not free unfortunately.
So, basically the question is 2 fold :
(1) Does anyone know how to extend the passowrd policy on Apache DS, such that we can support mixed case character enforcement. eg password must contain a mix of upper case and lower case chars aswell as atleast one digit etc etc. Or is this out of the box? I personally couldnt find any documentation on it?
(2) Does anyone know of any good and free LDAP servers that support this sort of stuff. Any ideas please?
Many Thanks,
R
After all of this, we finally found 389ds (ironically the last one we investigated). This we found was the best (for our needs anyway). The reason is that, it is has a great administration UI, does everything we need to do out of the box, plus, best of all, it is available in a costed option under RedHat. We didnt take the supported option, but nonetheless, as it is supported by RedHat, the documentation , we found was superb. Therefore, we felt confident that everything we needed to do wasexplained 100% rather than with some of the others, was half explained on some unmaintained wiki. So we advise all to look at 389ds.
I know ApacheDS doesn't support any extensions for ppolicy checks, can you file a feature request on ApacheDS's JIRA? We might try to get this included in the upcoming release.
I have filed this request https://issues.apache.org/jira/browse/DIRSERVER-1858
You should look at the http://forgerock.com/ OpenDJ which is an active and supported if you subscribe spin from OpenDS.
-jim
I'm about to create an application that uses JSON to update its content.
This is how I planned it to work:
When application starts, it checks (with internet connection is available) if the JSON file set on remote server is newer than the one stored localy - if it is then it's downloaded.
Then, the application applies data from that JSON to the content. For example, to the "Contact" information - it applies data like phone numbers etc.
My question is, is it in your opinion, a good technique to update appliactions content?
Does anynone had an experience with building app with this kind of idea?
Best regards,
Zin
Of course you can do this. One thing that may lead to a better user experience would be to ask the user for his permission to download new content (if there is something new).
This is a normal thing to do. I have a phonebook app that does exactly this. On a side note, if you need a network class to handle the web-service interaction, see this SO post. I wrote a custom network class that works with AFNetworking.
I would like to be able to generate custom bit.lys (http://bit.ly/thecakeisalie type things) through their API. This does not appear to be possible, but I thought I'd check; does anyone happen to know otherwise?
This unfortunately had to be removed for our free users due to on-going abuse. All of the custom bitlinks on bit.ly are created in the same key space, so allowing for automated creation there quickly leads to there being no sane options availble for anybody else.
That being said, we have recently added the ability for our paid customers to create custom bitlinks if they are using a custom domain. In this case, our customers get their own key space so creating custom bitlinks en-mass isn't a problem.
It was removed from the API. I like many others were trying to do this and bit.ly's support email replied saying it has been removed. Similar experiences on their ApiDocumentation wiki here.
I'm a new REST convert and I'm trying to design my first RESTful (hopefully) api and here is my question about addressing resources
Some notes first:
The data described here are 3d render
jobs
A user (graphics company) has multiple projects.
A project has multiple render jobs.
A render job has multiple frames.
There is a hierarchy enforced in the data (1 render job
belongs to one project, to one user)
How's this for naming my resourses...?
https:/api.myrenderjobsite.com/
/users/graphicscompany/projects
/users/graphicscompany/projects/112233
/users/graphicscompany/projects/112233/renders/
/users/graphicscompany/projects/112233/renders/889900
/users/graphicscompany/projects/112233/renders/889900/frames/0004
OR a shortened address for renders?
/users/graphicscompany/renders/889900
/users/graphicscompany/renders/889900/frames/0004
OR should I shorten (even more) the address if possible, omitting the user when not needed...?
/projects/112233/
/renders/889900/
/renders/889900/frames/0004
THANK YOU!
Instead of thinking about your api in terms of URLs, try thinking of it more like pages and links
between those pages.
Consider the following:
Will it be reasonable to create a resource for users? Do you have 10, 20 or 50 users? Or do you have 10,000 users? If it is the latter then obviously creating a single resource that represents all users is probably not going too work to well when you do a GET on it.
Is the list of Users a reasonable root url? i.e. The entry point into your service. Should the list of projects that belong to a GraphicsCompany be a separate resource, or should it just be embedded into the Graphics Company resource? You can ask the same question of each of the 1-to-many relationships that exist. Even if you do decide to merge the list of projects into the GraphicsCompany resource, you may still want a distinct resource to exist simple for the purpose of being able to POST to it in order to create a new project for that company.
Using this approach you should be able get a good idea of most of the resources in your API and how they are connected without having to worry about what your URLs look like. In fact if you do the design right, then any client application you right will not need to know anything about the URLs that you create. The only part of the system that cares what the URL looks like is your server, so that it can dispatch the request to the right controller.
The other significant question you need to ask yourself is what media type are you going to use for these resources. How many different clients will need to access these resources? Are you writing the clients, or is someone else? Should you attempt to reuse an existing standard like XHTML and classes/microformats? Could you squeeze most of the information into Atom? Maybe Atom with some extra namespaces like GDATA does it? Or is this only going to be used internally so you can just create your own media types, like application/vnd.YourCompany.Project+xml, application/vnd.YourCompany.Render+xml, etc.
There are many things to think about when designing a REST api, don't get hung up on what your URLs look like and you should really try to avoid doing "design by URL".
Presuming that you authenticate to the service, I would use the 1st option, but remove the user, particularly if the user is the currently logged in user.
If user actually represents something else (like client), I would include it, but not if it simply designates the currently logged in user. Agree with StaxMan, though, don't worry too much about squeezing the paths, as readability is key in RESTful APIs.
Personally I would not try to squeeze path too much, that is, some amount of redundant information is helpful both to quickly see what resource is, and for future expansion.
Generally users won't be typing paths anyway, so verbosity is not all that bad.