Google Adsense Publisher ID is how many characters. When I look at the publisher IDs I have, I see a total of 16 characters.
Is there a google publisher ID longer than 16 characters?
pub- next numbers 16 characters. Does it have a longer publisher ID?
pub-3358186650566504
pub-3685135352464177
pub-7104543801500968
pub-5610649146674306
pub-6042571565839072
pub-3268638132077067
pub-9328633604439863
Referring to AdSense Help, they don't explicitly mention that the ids have exactly 16 digits.
But they seem to do at least for now.
Your publisher ID looks like this: pub-1234567891234567.
The id looks long enough to me but you may want to be cautious and expect more digits.
Related
I am writing a tool to backup my mails. In order to understand if I have already backed up a mail I use the entryID.
The Entry ID is however very very long and so I have problems in serializing my datastructure with JSON, using the entryID as index in a hash.
Furthermore I noticed that the first part of the entryID remains identic throughout all my mails. Therefore my suspect, that the first part identifies the Outlook Server, and the last part the e-mails themselves. Therefore there should no need to use the whole entryID to identify a single mail in my account.
Anybody knows the syntax of this entryID, I did not find nothing on the Microsoft Site, maybe I did the wrong query.
Thx a lot
Example of EntryID:
00000000AC032ADC2BFB3545BD2CEE24F67EAFF507000C7E507D761D09469E2B3AC3FA5E65770034EA28BA320000FD962E1BCA05E74595C077ACB6D7D7D30001C72579700000
quite long, isnt´t it ?
All entry ids must be treated as black boxes. The first 4 bytes (8 hex characters) are the flags (0s for the long term entry id). Next 16 bytes (32 hex characters) are the provider UID registered with the M
Say I have a Products array in my Mongodb. I'd like users to be able to see each product on their own page: http://www.mysite.com/product/12345/Widget-Wodget. Since each Product doesn't have an incremental integer ID (12345) but instead it has a BSON ID (5063a36bdeb13f7505000630), I'd need to either add the integer ID or use the BSON ID.
Since BSON ID's include the PID:
4-byte timestamp,
3-byte machine identifier,
2-byte process id,
3-byte counter.
Am I exposing secure information to the outside world if I use the BSON ID in my url?
I can't think of any use to gain privileges on your machines, however using ObjectIds everywhere discloses a lot of information nonetheless.
By crawling your website, one could:
find about some hidden objects: for instance, if the counter part goes from 0x....b1 to 0x....b9 between times t1 and t2, one can guess ObjectIds within these invervals. However, guessing ids is most likely useless if you enforce access permissions
know the signup date of each user (not very sensitive info but better than nothing)
deduce actual (as opposed to publicly available) business hours from the timestamps of objects created by the staff
deduce in which timezones your audience lives from the timestamps of user-generated objects: if your website is one which people use mostly at lunchtime, then one could measure peaks of ObjectIds and deduce that a peak at 8 PM UTC means the audience was on the US West coast
and more generally, by crawling most of your website, one can build a timeline of the success of your service, having for any given time knowledge of: your user count, levels of user engagement, how many servers you've got, how often your servers are restarted. PID changes occurring on weekends are more likely crashes, whereas those on business days are more likely crashes + software revisions
and probably find other info specific to your business processes and domain
To be fair, even with random ids one can infer a lot. The main issue is that you need to prevent anyone from scraping a statistically significant part of your site. But if someone is determined, they'll succeed eventually, which is why providing them with all of this extra, timestamped info seems wrong.
Sharing the information in the ObjectID will not compromise your security. Someone could infer minor details such as when the ObjectID was created (timestamp), but none of the ObjectID components should be tied to authentication or authorization.
If you are building an e-commerce site, SEO is typically a strong consideration for public URLs. In this case you normally want to use a friendlier URL with shorter and more semantic path components than an ObjectID.
Note that you do not have to use the default ObjectID for your _id field .. so could always generate something more relevant for your application. The default ObjectID does provide a reasonable guarantee of uniqueness, so if you implement your own _id allocation you will have to take this into consideration.
See also:
Create an Auto-Incrementing Sequence Field
As #Stennie said, not really.
Let's start with the pid, most hackers wouldn't bother looking for a pid, on say Linux, instead they would just do:
ps aux | grep mongod
or something similar. Of course this requires the hacker to have actually hacked your server, I know of no public hack available based on the pid alone. Considering the pid will change when you restart the machine or mongod, this information is utterly useless to anyone trying to spy.
The machine id is another bit of data that is quite useless publicly and, to be honest, they would get a better understanding of your network using ping or digg than they would through the machine id alone.
So to answer the question: No, there is no real security threat and the information you are displaying is of no use to anyone except MongoDB really.
I also agree with #Stennie on using SEO friendly URLs, an example which I commonly use for e-commerce is /product/product_title_ with a smaller random id (maybe base 64 encode the _id) or a auto incrementing id with .html on the end.
I don't know much about the use of some random strings in URL.
As far as I used, I learned that it can be used where any user simply cannot guess the URL.
First noticed in phpmyadmin, as blowfish secret. and the URL said token=secret . I don't know about tokens.
My questions is - What are these strings anyway and are these random strings called tokens ?
There are many different uses of random strings in URLs. Your question is difficult to answer because you give us no examples, but I can describe one possible use.
A commercial site may allow users to create wish lists of products. The site may want users to be able to forward friends the URL of their wish list, but make them hard to guess. This can be implemented by adding a WishCode to the User record. Any time a user makes a wish list, create a string of random URL-compatible characters:
UserID Name WishCode
1076 Joe Bloggs a792f207a98d7db431bf3a56ab364e35
When the user adds a product to his wish list, add the product code to a Wish table:
UserID productID
1076 483692
1076 547320
1076 73028
Make the Wish List page accept a WishCode URL; e.g.:
http://myCompanycom/wishlist/a792f207a98d7db431bf3a56ab364e35
When a browser submits this URL, look up the UserID from the User table, and generate a page with all the products from this user's wish list. Note that it is very difficult to guess a valid wish URL.
Also note this has nothing to do with hashing, secrets, or passphrases, nor would I call this a "token". They are unrelated concepts.
What is the maximum length of a facebook name, the one you get in the parameter "name" from the graph API.
Maximum length of a Facebook username is currently 50 characters.
While trying to create a "really long name" as #BK suggested, the Facebook user account view complains with anything of 51 characters or greater:
I'm pretty sure that its not documented anywhere, but my guess would be 50 as the longest one I've seen after looking over several hundred thousand users is 49.
Ron Bowes posted a torrent with over 100 million Facebook user names. You could pull that down and query it if you really wanted to know. Or try creating a Facebook account with a really long name.
I recently encountered a unicode name (first & last name combined) that exceeded 255 bytes, unfortunately I don't recall how many characters specifically, but it broke our varchar(255) database field.
When using the SOAP API to work with salesforce.com (SFDC) it seems that the primary key in the underlying database is Id. Well there seems to be two representations of this value as either a 15 character version or an 18 character version.
I have been using the 18 since it is clearly more specific, but what is contained in the last three digits, that they can be dropped, seemingly?
Anyone understand what this is all about?
From the Web Services API Developer's Guide:
ID fields in the Salesforce.com user
interface contain 15-character,
base-62, case-sensitive strings. Each
of the 15 characters can be a numeric
digit (0-9), a lowercase letter (a-z),
or an uppercase letter (A-Z). Two
unique IDs may only be different by a
change in case.
Because there are applications like
Access which do not recognize that
50130000000014c is a different ID from
50130000000014C, an 18-digit,
case-safe version of the ID is
returned by all API calls. The 18
character IDs have been formed by
adding a suffix to each ID in the
Force.com API. 18-character IDs can be
safely compared for uniqueness by
case-insensitive applications, and can
be used in all API calls when
creating, editing, or deleting data.
If you need to convert the
18-character ID to a 15-character
version, truncate the last three
characters. Salesforce.com recommends
that you use the 18-character ID.
I know this is an old post, but just in case it is useful to someone...
If you want to do ad-hoc conversions of Id's, rather than programatically, then this Chrome extension makes it easy:
https://chrome.google.com/webstore/detail/sf-15-to-18/cogllpmaoflgaekieefhmglbpgdgmoeg
FYI - I'm the developer. Please use the feedback form on the app if you'd like to suggest any improvements or additional functionality.
Thanks!